I have already complained about Tuple Madness with reference to Python and Ruby, and UncleBob has seen the same problem and noted it on the old blog. I have come to realize that the same problems appear in modern C++ code.

If you are doing test-first development, you are likely to find your old coding conventions are no longer valid. There are a few changes you will need to make to your coding standards and practices.

I love python.

I love the simplicity, the nice data types, the strong dynamic typing, the significant indentation, the runtime flexibility, the list comps, the generators, they way that I can get work done in Python. I love the built-in help. I dig the Tao of Python.

There are still a few bits that seem artificial and clumsy. I was told that you don’t really know a language if there are not five things you hate about it. I have more than five, but these will do for now:

I’m not sure if there is already a code smell name for this situation. The idea is rather like “Large Class” or “God Class” but isn’t really related to behaviour. It’s just a matter of dependency.

Michael Feathers refers to “horrible include dependencies”, and that’s the right idea.

Pair programming is a very powerful development practice. It’s a great way to learn, to solve hard problems, and to write really excellent code. However, there are a number of human issues that can make pairing more difficult than it needs to be. Synergy is a tool that has helped me solve many of those problems. Here’s how…

I’m not crazy about TUT, but a customer is using it on a project and wanted to get a little assist from VIM. I don’t blame him. It’s a pain to keep track of your test number and there’s always more testing that we’d like in our test frameworks.

These are my own personal recollections. I’m probably wrong about some of it. If any of the other folks involved have a clearer memory of the events, please don’t hesitate to comment.

Yesterday, I blogged about TDD in C++ and ended with a suggestion for the dilemma of needing optimal performance some of the time and optimal productivity the rest of the time. I suggested that you should use more than one language for your applications.

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.