Sometimes, technical terms might seem overkill. But the goal of language is to allow us to communicate.

In the progress of rewriting agg (doing it right this time) I witnessed how your word pool can also influence your thoughts. Once I've learned a taxonomy of test doubles (objects used to test other objects), my mental models of the tests became more concise and I could refactor the test suites to have a better structure and cleaner code.

To share my enlightenment, you can find the taxonomy on http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html.

People often measure size or complexity of a software project by counting Source Lines Of Code. While this can often show whether some source code is large or not (and therefore provide relative and crude estimates about productivity), relying on it can be fatal.

Textual source code can be considered to be only one arbitrary representation of software[1]. Depending on the language chosen the complexity of the code can vary greatly. I also hope it's obvious to any regular reader of this blog that systems have more than two dimensions, which instantly proves that the SLOC count can't tell anything about the complexity of the software.

Worse, while textual representation is two-dimensional, SLOC measures only one of it. Thus, trying to control complexity by creating constraints on the amount of SLOC is obviously critical.

If the code wants to grow, be it because of a rudimentary programming framework, better understanding of the problem by the programmer or something else, it can reach its upper limit without the problem becoming any more complex inherently. In fact, additional code might make the system even less complex.

When the vertical bound is (close to be) reached, growth will continue in horizontal direction. And hundreds of characters long lines with several statements are far more problematic than just adding them above.

Code growth should not be prohibited per se. It should be closely monitored whether it is benign. And as long as it is, it is the job of the programmer to transform the code so that it always has the best design possible.

1. See also CodingStandardsAreMisleading

Some weeks ago, I finished reading Eric Raymond's The Cathedral and the Bazaar (the book). Raymond presents a thorough analysis of the hacker culture and invites the reader to a journey of self-reflection (provided she's part of that culture and hasn't done it so far). I'd recommend reading it -- maybe except for The Magic Cauldron. I'm not that down with that kind of economics in this context.

The analysis of the bazaar model was probably the most interesting one. I was surprised when I recognized its parallels with eXtreme Programming.

One of the lessons Raymond mentions is Release early, release often. And listen to your customers. He goes on and mentions the importance of constant, even daily improvement that should be visible to the users[1], giving them an ego-satisfying piece of action and keeping them motivated. Raymond claims that this is one the main reasons of Linux' success.

But these are also the cornerstones of agile methodologies, namely points 1, 3, 4 and 5 of the Manifesto.

Of course there are differences. The bazaar model is just an analysis, a set of guidelines for other hackers; agile methodologies are aimed at professional firms working for customers. Agile methodologies are realized by formal processes, while collaborations in the open source culture seem to evolve informally. But the similarities are interesting.

1. In this context, this includes (potential) co-developers as well.