Thinking Inside a Bigger Box

Three years ago, I was asked by one of our teams to give advice on how they should write a parser for a structured file format. Just having read up on SAX again, I recommended that they looked into designing it as a push parser. A push parser works by the design that the parser generates events each times it reads parts of the input. These events are sent to an event handler, which then builds up the internal object structure or whatever the program needs. A push parser is a very object-oriented approach to parsing.

About a year ago, I took over the reigns, as it were, on this project. The strategy I had recommended had resulted in a horrible design. After having spent a total of a few weeks to fix issues with it, I finally gave up and rewrote it as a simple procedural parser. The rewrite took me three days plus about a day of fixing some edge case bugs. The resulting code was a tenth the size of the push parser.

This leads to my dilemma: As a senior professional, what should I do when I’m asked to give advice on software design?

Object-oriented programming holds the promise that technical people not involved in a project can understand the code in the project by understanding the structure. In my experience, this often leads to the disease of architecturitis.

Architecturitis is the state of a program where important-seeming elements of the system are needlessly separated out from the rest, either as objects, or as distributed components. The result is that the program as a whole is less coherent. In order to understand what the program actually does, a programmer will have to understand many separate pieces with lots of plumbing between them.

My temptation in order to avoid architecturitis is to say “just do what seems best to you”. This answer is also a non-starter. This sort of advice is useful for people who have lots of experience, but haven’t learned to trust themselves yet. But to those who feel lost at sea, something more substantial is needed.

For the longest time, I thought that testing was the way to go. But writing good tests is really hard, and it’s a skill that doesn’t come natural to developers. Without the sufficient understanding and experience with testing, the advice to “start by writing the tests” will just result in developers not doing anything at all, or, perhaps worse, write tests that make the program harder to change.

“Write tests first” is no magic bullet. But unlike the path of “architecturitis”, I know what to look for and point out in good tests. And I know how to practice getting better. Practice, then is key to learning. Hardly ground shaking. But in the software profession, we set aside very little time to practice. “Learn on the job” is supposed to be the only form of practice.

Writing good code is a long path, and the practice of writing tests first provides a set of goal posts along this path.