[This article is a rerun from the old blog. Because the matter is still interesting (to us) we migrated and republished it.]

Today I want to answer a question which I  pondered about for quite a long time:

»What does lightweight really mean?  Does it mean anything at all?«

What annoyed me most was that everyone nowadays seems eager to point out (MULTIPLE TIMES AND IN CAPS) how lightweight his process or framework or whatever is supposed to be. The fact that no one seems to gloat over the fact how »heavyweight« their product is arose the suspicion in me that the whole heavy- vs.  lightweight comparison is more a marketing- or coolness thingy than something helpful to dispute or even base decisions and strategies on.

I deliberately used past tense in the last paragraph because thanks to Lu Kim Man and Keith Chan these times of doubt are finally over for me! In their book »Software Development Rhythms«  these guys give a definition of »lightweight« even  I can understand an use:

The weightiness of software processes and practices is a matter of the values that arise from them and the degree to which activities directly benefit and contribute to core developers (i.e., people) and core software programming (i.e., products). [...] For example, a software process that requires writing all-embracing design documentation for commercial database applications may be considered heavyweight as it does not directly create value for the core development.

They further state:

Heavyweight processes have their place. In this case, detailed documents come in handy when we are going to outsource technical support and software maintenance abroad.

This finally makes the term a useful tool to use in discussions and for decision making. The meaning is clear and the trade-off between the extreme opposites can be assessed and evaluated in concrete contexts.

For those wondering: The emphasis of people and product in the quotation refers to the agile mantra »People over Processes, Working Code (=product) over Documentation. Seen this way one could reason that »the more lightweight you do the more agile you are (little padawan)« but this is a job for the evangelists out there which I don’t want to awake with my humble shenanigans. If you are interested in my opinion: It’s BS.

Let’s summarize:

• The weight of a tool or process can be defined as: »How directly do developers and programming tasks benefit from it?«  In other words: If the answer to »Does it speed up development in the short term?«  is Yes we are on the lightweight track.
• Sometimes we sacrifice short term benefits in favour of long term, project overarching goals. By doing this we enter the heavyweight realm.
• There is place for both strategies. Neither one is evil.

Amen.

Can you live with this definition? How do you define »lightweight«?