Don't Architect, Refactor

The test-driven development mantra is "red, green, refactor," but we far too often let other things creep into the process.  One of these things is domain knowledge.

Back in February, Gojko Adzik described his experience with Keith Braithwaite's "TDD as if you meant it" exercise. He was to TDD whether a stone in the game of Go could be taken, or not.  In the game of Go, each piece is placed on a grid and can be taken if it is surrounded by only one liberty  (i.e. free space) in any of the four cardinal directions.

His first test was to identify stones with two corners covered as having two liberties.  Yet, despite that, and armed with additional domain knowledge, his test started out like this:

GoGrid grid=new GoGrid(3,3);

See it?  Yeah, the first and only line.  It's a domain leak. And it's not just Gojko -- I do it all the time, inadvertently of course. Rather than starting off with the simplest thing that could possibly work, we have a tendency to inject domain knowledge into our code. Suddenly we find that we must create a few classes rather than a few short lines of code.  We've made our job harder and started forcing a design that didn't exist nor evolve from the code.  Our leaky domain knowledge introduces untested design, BDUF, but on a smaller, slightly less turgid scale.

With TDD,  the design is supposed to evolve, yet I often find myself saying, "this is easy to code, but...."  And the but kills me, it's usually something describing a design or architecture problem that I don't know how I'm going to solve, so I sit there thinking, and thinking, and thinking.

"Stop! Don't architect, refactor," I must tell myself. That is, I need to implement what I know, worrying very little about the design.  Writing the initial code isn't about having the best, most-pure design the first time.  The refactoring step is about cleaning up the design.  It's also been said this way, "Make it work. Make it right. Make it fast."

Test-Driven Development Justified

I stood in shock, in utter awe and amazement.  I was talking with one of the lead programmers of an open source project, with whom I'd been in discussions countless times over the last few years.  He was a programmer who commanded my respect, and the respect of everybody else in our IRC community.  He wrote software that was virtually bug free and did exactly what it was supposed to.   He used the idioms of the language, appropriate patterns familiar to capable programmers, and consistently demonstrated a sound understanding of theory vetted with practicality.  And yet, despite all of this, he didn't know what TDD was.  To be fair to him, I bet he did, but he didn't recognize the acronym and asked me what it meant.

The TDD Tax

Misko Hevery recently mentioned a tax associated with testing.  I personally read that as the tax associated with TDD, which may or may not be exactly what was intended.  What exactly is that tax and how can we separate the necessary part of the tax from the unnecessary?


Let me frame the details of the tax in light of a commercial project that has essentially taken 1.5 years, full time.

Project Total	Lines	Chars	Chars /Line
All Source	75478	1939605	27.02
Unit Tests
Backend	2,116	52,755	24.93
Model	5,972	168,279	28.18
Main	1,004	23,302	23.21
Utils	4,178	102,358	24.50
Widgets	8,747	251,869	28.79
Core	702	16,256	23.16
Support	157	3,272	20.84
Total	22,876	618,091	27.02
Project Total	75478	1939605	25.70

The statistics above describe a desktop application written with Qt.  Unit tests were written with Qt's QTestlib which allows almost all interactions with widgets to be tested programatically.  Qt supports a model-view architecture which also helped test the GUI components. The application consists of about 75 thousand lines of source code and 23 thousand lines of tests.  The project actually should have more tests, but we weren't diligent enough at the time (and we regret it now).

Typing Tax


The first part of the TDD tax is the required extra typing.  I'd like to believe that everybody knows that being the fastest typist in the world does not make them an uber-efficient, super effective programmer.  Rather, typing speed has very little impact on the quality or effectiveness of a programmer.


How much is the typing tax? I type about 100 words per minute (WPM) for standard text, so let's assume that I can only type 60 when programming, because of all the extra special characters.  Although WPM has different definitions, I'm going to use five characters as a word.  Thus, 618,091 chars / 5 chars/word gives me 123618.2 words.  And 123,618.2 words / 60 WPM = 2060.3 minutes.  And 2060.3 minutes / 60 minute/hour gives 34.34 hours.


Yes, only 34.34 hours.  I could type the entirety of my unit tests in only 34 hours... in less than one forty hour work week.  In table form:

Words @ 5 chars/word 123618.2 Minutes @ 60 WPM 2060.3 Total Hours: 34.34

Unfortunately, I didn't keep track of time writing the tests, so I don't know what percentage of the time I spent writing tests and what percentage of the time I was developing production code.  But, for sake of this blog post, I'm going to assume 10% of my total development time was dedicated to writing tests.


That means that I spent about (1.5 * 52) * 40 / 10 = 312 hours writing tests.  Of that time spent writing tests, 34 hours, or 9.1% was spent typing.  The other 277 hours or 90.9% was testing related.

Breaking it Down Further

Where else was that 277 hours spent? Some of it was inevitably spent trying to figure out how I could test a certain part of the application.  Should that be part of the TDD tax?  Perhaps, but if I'm striving for quality, I am still going to test it somehow, aren't I?

In some cases it will be easy to test manually and difficult to test programatically, such as with unit tests.  In these cases, it could be said that I'm paying a tax.

I'm not sure how else I might be spending that time.  I imagine some of that is spent deriving and discovering yet unknown requirements.  Time is likely also spent working on some design related activities -- trying to discover how different pieces of the application can best fit together.  Another small portion of that time will be spent running the unit tests time and time again.

ROI


What I'm really doing, throughout this process, however, is making a deposit against the need to run the tests multiple times.  The more times I run the test, the more payment I get back; it compounds, like interest.

A bunch of different numbers wouldn't mean much here.  For a one off project, or a project whose requirements are truly known up front, perhaps the tax associated with TDD isn't worth it.  On most real-world projects, however, requirements will change... a lot.  And each time a requirement changes or part of the application is re-written, the automated tests pay interest.  I can change, replace, or re-write large chunks of functionality and know with certainty that I haven't changed any important behavior.

If you haven't tried paying the TDD tax, you should; you might find you'll later need to collect some of its interest.  When you've diligently attempted TDD, spread the word for many still don't know about it. Even if it doesn't work for your situation, it might work for theirs.

Beans, Ping-Pong Balls, and Priorities

Not too long ago I found my wife placing ping-pong balls followed by beans into a canning jar. After briefly trying to reason about what she might be doing, I asked her.  She explained that she was preparing a lesson about priorities for the children in her church primary class, and then elaborated.

The canning jar represents our day.  Each day certain important things need to be completed.  These are represented by ping-pong balls with a label summarizing the task.  The beans represent other things that occupy or time throughout the day. The bean could represent inconsequential, such as spending a few minutes watching the news, or something necessary, such as eating a healthful meal.

Daily Organization

How should the day best be organized to accomplish all necessary tasks?

Possibility 1 - tackle the small tasks first.


Each small task is accomplished and each bean is placed in the jar until none remain.  Next, the larger tasks are attempted.  But, before long, there isn't any more room and it becomes impossible to accomplish all of the larger and more important tasks.

Possibility 2 - tackle the priority tasks first.

As each task is accomplished, the representative ping-pong ball is placed in the jar. Next, the remaining smaller tasks are completed and the beans placed into the jar.  These beans flow easily around the ping-pong balls, and the jar is quickly filled.

Priorities & Analogy

Which of our daily tasks are ping-pong balls, and which are beans?  The following are on my priority (ping-pong ball) list:

• Test-Driven Development (TDD)
• Pair Programming
• Refactoring
• Testing
• User Interface Design / User Interaction Design
• Self-Improvement

Bean Accrual Patterns

Of course, it’s likely quite obvious that if we fill our day with little inconsequential things, we’ll eventually run out of time to accomplish important,  priority tasks.  So, why the comparison?

We accrue beans in two different ways.  First, when we choose to work on tasks that aren’t truly important or become distracted with tasks not pertinent to our goals and priority tasks.  Good time management skills like those taught in the Pomodoro Technique can aid much in this regard.

The second accrual pattern is not a time management issue, rather, it’s a result of less-than-ideal software or code quality, which I’ll define as not as good as it could have been.

When developing using TDD, tests come first.  Of course, I’m not going to purposefully create an API for myself that’s difficult to test.  But, when I don’t do TDD, it will inevitably happen.  I’ll end up doing something that makes it harder to test and not as good as it could have been. My bean has now been created.

But in reality, it’s likely worse than that.  I didn’t create just one bean, rather, I created many beans:

• A turgid or fragile design
• A hard to test design
• A manual testing requirement
• Increased cognitive load
• Decreased understanding of requirements
• (Likely) increased coupling

Without TDD, as soon as I go to test that piece of software, it’s going to take longer because I will have missed something, making it harder to test.  As soon as a requirement changes, I’ll need to manually re-test the necessary pieces.When a change request comes through a couple of months down the road, I won’t have good, concise examples of how to use that code, and it will take me longer that it could have.

Yes, there is a tax, of sorts, associated with TDD, but what about the ROI?  Unless you’re absolutely sure it’s negative, I recommend it.  Oh, and don’t forget, you can’t measure ROI one minute after investing, it’s a long-term investment.

Other Beans

Throughout the years that I've been programming, I've seen days and even weeks fill with beans:

• When I don't do TDD, my code is not as good as it could have been.
• When I don't do pair programming, I’ll miss something important or do something dumb
• When I don't adequately refactor, my design degrades
• When I don't sufficiently test, either before, during, or after coding, I'll end up rewriting some aspect of my design

A few beans don't matter.  Nobody will notice... and it's easy to justify just a few beans.  The problem comes when you've amassed so many you now have a collection.  This is technical debt.

Bean Removal

Technical debt must be paid down before the interest accrues too rapidly.  Each day, beans, our daily impediments, must be removed, and we must remove more than we create each day; we must shovel our way out.  Unfortunately we can't usually start with a big shovel, we usually need to start with a hand trowel, slowly removing the encrusted dirt and debris. Eventually, we'll be able fit in one more ping-pong sized, important task. And then two... and then three. Given enough persistence, you can turn that brown field green.