Michael Eriksson
A Swede in Germany
Home » Software development | About me Impressum Contact Sitemap

Remarks on this category

Use of “developer” and other role names

I will typically use the word developer when referring to anyone involved in the actual development (not including specification, testing, maintenance): Coders, programmers, (software) designers, architects, engineers, whatnot.

The main reason is that the exact role of any individual discussed is often not relevant to the discussion. Should an exception occur, I will not hesitate to use a more specific term.

Further, the other terms are often poorly defined, have varying meanings from organisation to organisation, greatly overlap, or are otherwise unsuitable. Often the distinctions are even artificial (in particular, in small organizations) with a developer spending time doing anything from coding to architecture (and a number of other things too, e.g. documentation or database administration). In fact, there are some developers who argue that “programmer” is the only term worth using. I would not go quite as far, noting that the ranks of programming are evermore flooded by people who have no idea of what they are doing—just like any other profession. (Whereas, in the past, the average “quality of mind” was noticeably higher than the global average.) Further, “programmer” has over the years become associated with low-level work, and could be misunderstood.

Apart from “developer”, I will typically use the following words:

Coder:Someone who currently engages in the act of coding
Programmer:Someone whose main work is doing development at a comparatively low level of abstraction/conceptualization, and within a comparatively small scope of the application.
Designer:Similar, but at a mid level and a mid-range scope.
Architect:Similar, but at a high level and a wide-range scope.
Tester:Depending on context: Someone whose main work is testing, someone currently assigned as a tester (it is not uncommon for this to be a temporary role, assigned to whomever can be spared during a test phase), or someone who currently engages in testing.


The above list was added after a lot of content was already written. It may expand as I notice other uses in my writings (or, obviously, add new texts).

“Tester” is a complication: Only when writing the list, did I realize the multiple uses the term has in my own thinking. I may need to introduce additional, more differentiating, words later.

Other issues relating to terminology

I will typically use “application” as the word for an end-product; including e.g. libraries, where the word, in the strict sense, does not apply. (Beware that not all libraries are end-products.) Alternatives, e.g. “program”, have similar or other complications.

“Artifact” in turn, will often be used as a more generic word signifying a reasonably stand-alone (in the current context) unit—it could be an application, an individual class, a library, ...

There is a great confusion from language to language about what to call methods/functions/procedures/sub-routines/routines/whatnot. Mostly, I will go with the Java convention of “method”, glossing over the differences that often occur between the exact meanings of various terms. On occasion other words will be used, e.g. when specifically discussing a non-Java language. (Similarly, I tend to use Java terminology for other programming concepts.)

Code-centric view

I often discuss issues from a code-centric view. This does not mean that the discussions apply only to code—on the contrary, they are very often valid over a wide range of activities, including (m.m.) design and architecture. For more general principles they need not even be limited to software development.

The reasons for this choice include:

  1. Code is relatively hands-on, and it is easier to write good examples and express thoughts concerning code than, say, architecture.

  2. While opinions on what is good code, coding practices, etc., can vary, the differences in opinion on higher levels are much greater. Further, the accumulated knowledge that humanity has on more abstract levels is significantly smaller than where coding is concerned.

  3. All developers will typically have a background in coding, likely even do coding to a high degree even today; beginning programmers, OTOH, will rarely have non-trivial experience of more abstract levels. (The hobby programmer, obviously, will typically have no such knowledge at all; but he is also unlikely to read these pages.)

  4. Without developing an understanding of code, it is hard to become a proficient designer or architect (even when actual coding has become a thing of the past)—it can even be argued that many deficiencies showed by e.g. project managers would be diminished if they had some understanding of coding.

  5. Coding remains at the core of software development: It can be argued that most other activities are just attempts at compensating for the wish to build increasingly, sometimes ridiculously, complex and feature-loaded software. If the industry returned to the Unix philosophy (unrealistic wish) of “do one thing, and do it well, “small is beautiful”, etc., then we would have better software, less need for concerns about requirements, architecture, project management, ...—and coding would again become the main concern of everyone involved.


    This would also:

    Drastically reduce the number of developers needed, leading to a higher quality of the developer corps.

    Make it impossible for companies working along a Microsoftian model to make money. Notably, this marketing driven, add-more-and-more-features-so-we-can-sell-something-new, approach is responsible for much of the really third-rate software available today. Contrast this with, as a beautiful and contrary ideal, TeX πw.


    This is obviously from a development POV: The entire process involved will still involve other important factors, most notably finding out what the users want and need; however, this will all take place on a very different scale, in a different format, and with a different focus—e.g. in that the users actually needs are met, instead of building gigantic lists of what the users should need (from the POV of product management/business development) or what marketing and sales thinks will be attractive to various decision makers in other companies.

    Design and architecture, similarly, will remain important, but be smaller, easier to correct after the fact, often be doable by the individual developers (with very many projects only involving one developer in the first place). Etc.

Java-centric view

Having spent most of my career as a Java developer, I naturally tend to take a Java-centric view (unconsciously, through greater knowledge and greater drive to write about Java, or by wishing to aid other Java developers in particular), use examples written in Java, etc.

Again, however, this does rarely limit the validity of the principles discussed. Change the implementation details and most (not necessarily all) statements will be applicable to e.g. C, SmallTalk, and Perl.