« Javablogs' new layout needs tweaking | Main | Groovy: the more the merrier »

Ward Cunningham on growing an architecture

I hate it when a new requirement comes in that doesn't fit nicely, as if the program were designed to make the requirement hard. In that case, we have a lot of work to do. But the nature of the work is first changing the program so the new requirement is an easy fit, and then doing the easy work to incorporate the requirement. In other words, instead of patching the new requirement onto an architecture that was not made to accommodate it, just buckle under and do the hard work to change the architecture so the requirement is easy to implement. The patch approach means that the next guy who comes along will have to understand both the system that wasn't made to do the new requirement, and the patch that tried to overcome that system without changing it. It's much better to change the system to accommodate the new feature easily. [via Artima]
.

January 6, 2004 10:09 AM

Comments

Henri Yandell
(January 7, 2004 08:34 AM #)

Don't you love unit tests. The sane reply to this would be that such a huge change to the codebase will have a much higher chance of incorporating new bugs than a 'slick' hack and so there are many reasons to not 'buckle under and do the hard work'.

However with unit tests, the agile crowd can always just say that refactoring is cheap because of course you have 100% unit test coverage and no bug will ever get by them.

I am constantly in recode stasis because I know that, while I can happily redesign the system, throwing away half the unused code and reducing dependencies and overall making the system tighter, my decision to refactor is committing some test team somewhere to having to test, and I'm also tying any minor changes to mine [well, unless I go off branching etc, which introduces more chance of an error when it's re-merged].

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1135