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

Blog Refactoring

Software has to change, or it will become less and less useful[1]. Because of these changes, its design deteriorates[1]. Frequent refactoring prevents this deterioration[2], and thus allows the software to easily evolve further[3].

As software evolves, so does this blog. After about twenty posts, the problems of its structure became obvious. Thus, I spent some time refactoring the categorization scheme, re-tagged all posts and seperated categories from their archives.

I like the result. Neither semi-duplicate nor fuzzy tags. The tag cloud is clear and concise, and now it reflects the contents of this post very well.

If this should blast your feed reader, I'm sorry.

---

Footnotes

1. These are natural laws of software, first formalized by Lehman and Belady around the 1980's.
2. Or rather, undoes it soon after the problem is noticed.
3. Because maintainability and extensibility is much higher in well-factored than in interdependent spaghetti code.