Good enough

When doing XP development, I've found that the notion of "good enough" comes up a lot. It's a pretty common thing to have to think about when programming, but when you're pairing full time it's something that actually gets discussed directly instead of just going by your gut or by how ambitious/lazy you're feeling on any given day.

When writing code, as with most things in life, there isn't really a black and white concept of "done". Think about mowing your lawn - the point is to get all the blades of grass to a short, uniform length. How uniform your grass must be is really a matter of opinion. Do you let the lawn mower get it relatively close? Probably. Do you go around cutting every single blade by hand with a ruler? I hope not. Do you spend double the time to trim all the edges? Probably. Do you spent another 50% more time to trim that hard to reach part behind the planter that you can only see from that one specific angle? Maybe.

This same pattern applies almost directly to software. Do you make the code meet the requirements? Yes. Do you fine tune every single line of code for the utmost clarity? Probably not. Do you make the new API's you write as easy to use as you can? Maybe.

So how good is good enough? It's always a tradeoff between time and quality. When doing TDD/BDD the test suite can help you with this balance by giving you a safety net of tests to rely on. You can code with confidence that what you're doing will work and that it should play nicely with the rest of the code base. I think this lets people make the "good enough" call earlier than they might otherwise. If your test run green and your requirements are fulfilled you're done, right?

Usually this is great - the sooner you can confidently say "good enough", the sooner you can start working on the next feature. The time/quality scale has been shifted in your favor.

However, I think this safety net can lead people into other traps as well. If you always throw the "good enough" flag as soon as you can, you've become a high risk for technical debt. If you ignore the grass that grows behind the planter for too long, it can start to take over other parts of your yard, and now you have a big problem on your hands.

This problem definitely isn't specific to test driven projects - I've seen many a code base with the programmers gasping for breath in an ocean of debt. The difference I've seen in the TDD projects is that you can actually survive in these oceans. When you have your life jacket of tests strapped to you, the waves don't seem so scary. But again, I'm not sure that is really the best thing either.

One of the major reasons for doing TDD/BDD is that you increase your velocity. You can plow forward without having to worry about the past. However, like on any project, if you don't take time to keep things clean, the technical debt you'll accrue will quickly start to work against whatever velocity gains you made in the first place. Having a suite a of tests certainly helps, but it doesn't make you immune to these kinds of things.

So I issue this plea to all developers, those doing TDD and those not: Remember to take time to keep things clean and sensical in your code and I will do the same, as someday I may be in your code base and you in mine.