TDD: When does ‘Good Enough Code’ become not good enough?

David — Mon, 25 Jan 2010 21:47:49 +0000

Today I started try to refactor a piece of code that was causing me pain.
Dependencies were tangled together, classes were getting bigger, functions and names were losing their meaning and unit tests were becoming cluttered and hard to understand.
After few hours trying to tangle this code I started thinking that probably it would have been easier if we had tackled that a few features earlier.
When you are caught in the TDD cycle red – green – refactor it’s easy to focus only on small scale refactoring and losing the big picture. Also Bob Martin rule: “You may not write more production code than is sufficient to pass the current failing test.” might be misleading.
Dan North talks of “…deferring important architectural and design decisions until the last responsible moment”.
Is there an easy way to identify the last responsible moment?
I think for now on I will stick to this rule: as soon as I start adding a feature to a piece of code I will make sure that it respect fundamentals good practices (small functions that do one thing, command query separation, small classes that follows the single responsibility principle and meaningful names). I will applly the same treatment to tests.
I will probably spend more time caring about exception handling, good object modeling and so on, on the most used and strategic part of a codebase.
In order to identify those areas, keeping track on stories that takes longer than expected and the one with more bugs, might help.
What is your approach to this problem?

In the meanwhile you should follow me on twitter here

David Santoro » software craftmanship

TDD: When does ‘Good Enough Code’ become not good enough?