Heli’s Blog

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away (Antoine de Saint-Exupery)

Everything should be made as simple as possible, but not simpler (Albert Einstein)

What do these quotes, the Rube Goldberg machines, Occam’s Razor and the KISS principle have in common (Google and Wikipedia keep impressing me what you find by just searching for a simple little word)?
Well, they are all about SIMPLICITY (or lack thereof)!
Simplicity is also a central tenet in software engineering and development.
I’ve seen really great pieces of software that unfortunately were complex and awkward to use. I’ve seen classes that were simple to use, but that had so many different responsibilities that they were hard to understand and maintain. I’ve seen design rules that were supposed to make implementation for the programmers as easy as possible, but resulted in a big pile of overly redundant code (this is also not simplicity).
Simplicity is all about reducing this complexity as much as possible.
In software engineering, this principle should be applied wherever and whenever possible.
When designing and implementing, the class’s internals should be simple (not too much responsibility for a single class - this is where high cohesion comes into play), but also its interface should be simple (the Spring guys, for example, are doing a great job wrapping and simplifying complex third-party classes and components).
But this is also true for a system’s architecture. System components should be as simple as possible, resulting in probably more, but simpler components.
And last but not least, simplicity also makes sense for processes - the build process and the development process (I don’t want to use the agile buzzword here … oops, too late).
I think a good metric is, how easy it is to describe a component. If you can say in a few sentences, what a component does, then it is probably simple enough. This applies to classes, but also to system components or subsystems.
And a final note: the goal is avoiding complexity, not negating it.

Despite the already very ambitious subtitle of this blog Daily Dose of Software Engineering - and I mean the Daily part -, especially considering my posting habits in the past, I somehow managed to write my second post in just one day! Maybe a good omen…
This one is about a feature of an automatic build process.
We all know, that an automatic build process is a good thing (at least we should know by now). Along with the right tool and plugins, it makes sure that the code always compiles, the unit tests produce a green bar, the coding guidelines are respected by all developers and certain metrics are in a valid range.
Another feature that should be used much more often is, that pending implementation tasks (those nice TODO comments that a developer can put into his code if he is not really done yet) can easily be managed. Developers are usually very diligent adding such comments (mostly to defer dull or complicated tasks for later), and build tools have very good support for creating lists of those TODOs.
The problem is usually, that those comments are added to the code, the task lists are created, uploaded to the project’s developer web site, and … well, stay there without ever being checked (in the hot phase of a project, which is usually always, nobody wants to find some more skeletons in the project’s closet).
Here are some ideas that might help prevent this problem:

• If you don’t do that already, add those TODO comments whenever you defer some implementation task for later, and use your build tool to create a publically available list of those implementation tasks
• Before a release, the developers are responsible for checking their tasks, if they are relevant to this release (note, that you need to know, which tasks belong to which developer) and complete them if necessary (and then of course remove the TODO tags)

If these simple rules are obeyed, chances are small that your test team finds a bug, the developer looks for a possible fix, just finding a TODO comment saying exactly what should have been done in the first place to prevent this bug.
Finally, just a little story about a TODO comment we found some time ago - it was something like

  /*
   * TODO change this by version 5.3
   */

Well, believe it or not, we found it while adding some features for version 5.8 .
So back to our question TODO or not TODO? - the answer is definitely TODO!