More Work Or Less Work

There was a change made to a major visual component (GUI screen) in a group I've been coaching and observing. The guy who did the work is a really good guy, smart and professional. He has my confidence. Sadly, some bugs that had been fixed in the older code recurred.

When the code was originally written, the team was not doing TDD. It was easier back then, because you didn't have to write tests. Not only was the old code not tested, it was not testable. One of the reasons agile is "more work" is because you have to write testable code in order to pass the tests that drive the development.

All commercial code is written by people under tight deadlines and with plenty of pressure. It's not like they refused to do TDD, it just wasn't on the radar at the time. Without initial tests, the code was naturally not testable. After all, nobody builds waterproof guitars, since nobody plans to immerse them -- it's the same principle.

Be kind. We could be talking about YOUR pre-TDD code, you know? We're not talking about mine, but I know that I'd be a little embarassed at certain code features I would now consider tactical errors. TDD changes things.

When the team started going Agile, they didn't go back and "retro-test-drive" their existing code. In transition, people have to choose their battles. One of the choices was that all new non-gui code would be test-driven, and that the GUI was just too hard to make testable. This happens. Who can stop all forward progress in order to add batteries of tests to pre-existing code?

Eventually a lead techie realized that he could make the code testable using "presenter first" and so he test-drove the code into existence. Since there were no tests against the old code, some errors returned. It didn't feel like forward progress, but when you are working without tests and in a really crummy version control system you do the best you can. Luckily, the problems were uncovered pretty rapidly (in the same iteration, so far).

There are a few things I learned.

One lesson was that it is really hard to run the tests that nobody ever wrote. When you are working on code without a historical battery of tests, it is not easier. It is much harder. The level of personal effort involved in "due diligence" is such that it's likely (inevitable!) that not enough research can/will be done to ensure that there are no side-effects or regressions. Not having tests ready-made and ready-to-run means your mistakes will be more visible and more likely.

The second thing is that I really want to refactor any big changes into existence. This was a "clean restart" and it meant that some ground had to be lost (functionality/regression) in order for other ground to be gained (more testable internals). I don't know how hard that would have been. The change is in, and now it's comparitively easy to add more tests to stop these bugs from returning. I may choose to do some clean starts, but I'll chose carefuly when no historic tests are available.

The third is that even with these caveats, the techie was able to rebuild this major screen in relatively quick time compared to the original one. No, not only a few hours, but on the order of several days. The original took a really long time. If tests were available, even a wholesale rewrite of something deemed fairly major is not such a big deal. Throwing the first one away is not so scary.

My fourth point is that it would have been easier (had they known) to add tests one at a time as they needed them in the past than for this poor guy to research all the requirements, code quirks, and past bug reports. Then he would still have to write all the tests as part of this one code change (how many story points? A lot!). It's much easier to collect tests more casually over time.

This all keeps adding up to support the idea that maybe in the steady state it is easier to do agile projects than not to do agile projects.

!commentForm