In his post, “The Fallacy of Premature Optimization”, Mikhail Opletayev wrote:
“Just being aware of performance while designing a product will help tremendously- just like how one of the better ways to diet is to calculate how many calories you ingest every meal.
“Writing efficient code doesn’t take much more of your time, if any. In fact, it can easily be argued that writing efficient code actually saves you a lot of time in the long run.”
Now, Mikhail may have had another direction he was heading, but as I read his writing I immediately went back to Test Driven Development.
By itself, TDD is not about optimizing performance. One of the most fundamental acknowledgments of XP is that all the practices work together to produce the greatest value. So I am thinking more about how NOT practicing TDD impacts product performance.
In this case, the relevant side effect I highlight is the length and complexity of methods and algorithms when TDD is used and when it is not. In the TDD case, it can get really hard to test a method that is 2 pages long, so we end up breaking up our code into smaller fragments “just so we can test them”.
Really? At first glance, that is definitely the behavior I see. When people follow TDD principles, their code methods are shorter… and those who really hate doing TDD are often “algorithm-writers”, using longer and more complicated logic.
One side effect of short methods is less nesting within loops and conditional statements. Another is a tendency toward functional primitives that may be mixed and matched in a more reusable way. Patterns can then emerge that suggest refactoring into more flexible structures.
And putting these benefits together, the code is cleaner, shorter and easier to understand. It is tighter, more flexible and high performing.
Now… there is one caveat I will mention. Many agile developers shy away from documentation, but in the case of TDD (or any form of design) it is a huge benefit to first draw a picture… whatever picture is relevant – a class diagram, a sequence diagram, a doodle on a whiteboard or a napkin.
What you are searching for in your pictures is what XP calls “Metaphor”… the shared mental model of what you are trying to tackle. Without metaphor, TDD can breakdown into endlessly finer primitives and actually INCREASE complexity.
So, let me know: do you practice TDD? What can you say about its impact on code complexity? And what do you do to set up metaphor with your teams?