I spent all of June mentoring teams on TDD in C++ with some Java. While C++ was my language of choice through most of the 90’s, I think far too many teams are using it today when there are better options for their particular needs.

During the month, I took notes on all the ways that C++ development is less productive than development in languages like Java, particular if you try to practice TDD. I’m not trying to start a language flame war. There are times when C++ is the appropriate tool, as we’ll see.

Most of the points below have been discussed before, but it is useful to list them in one place and to highlight a few particular observations.

In cleaning up the code, I simplified the algorithm a very little and improved performance considerably. Amazing how that works, how simpler equals faster for so much code. Adding simple data structures, local explanatory functions, and the like often make code much faster.

I had a moderately interesting customer problem to work on. I got acquainted with a bit of legacy code that is seriously in need of some interface segregation. It’s an entirely concrete class and used from all over the code base. The question is how to segregate, and that depends on what methods are called from which programs. We ran ‘nm’ to extract the link table from our object files, saving me the trouble of parsing C++ (a scary thought) All that remained was for me to compare the method prototypes used by the object files and find the common sets.

All projects accumulate technical debt. It’s just a question of how much and what you do about it. My personal method for tracking debt is very quick, easy, and useful…

In the beginning the Product Owner created the Product Feature Request (PFR). And the Product Feature Request was without form, and void; and darkness was upon the face of the deep. And the Spirit of the Requirements Expert (RE) moved upon the face of the PFR. And the RE said, let there be requirements: and there were requirements. And the RE saw the requirements, that they were good: and the RE divided the light from the darkness. The RE called the light the functional requirements and the darkness was called quality attributes. And the functional requirements and the quality attributes were the first four months.

Here is my latest Craftsman article. Aphonse, Jerry, Jasmine, and the crew learn a little bit about Ruby, and fight about it’s benefits and dangers.

(with apologies to Steely Dan for the nearly-lyrical title)

I’ve noticed that “Do the simplest thing that might possibly work” gets universal agreement in principle, and great divergence in practice.

One of the things I love about TDD is that it takes all the scaffolding and collateral effort for creating a class, all indications of bad coupling, and makes them entirely visible. This is also one thing that makes it very hard to start TDD in legacy system.

When you realize that it’s very hard to test a class out-of-context, the right answer is to start decoupling each class so it can be run out-of-context. When we are successful here, tests run very very fast and are easily self-verifying and isolated. It is a beautiful thing even if it follows many ugly hours of painstaking work.

Professional software developers can and should maintain their own build system. We strive to deliver working software, not source code. However, if you want to shirk this responsibility, and you’re a Java programmer, and you use Ant, then there is a way out.

So, I’m pair programming C++ code with a client today and he makes an observation that makes me pause.

The well-structured, open-source code I’ve looked at typically has very few else blocks. You might see a conditional test with a return statement if the conditional evaluates to true, but not many if/else blocks.