Beware of slow descents into unmaintainability

I’ve actually been coding again recently which has been a pleasant change. Of course it’s pretty much impossible to balance this with my wider responsibilities of running operations but that’s another story…or perhaps more accurately another post.

Over the past year I’ve become a huge fan of the DTO / Presentation Model approach for screens. And 9 months ago that is how we approached the most complex screen in one of the web applications that we were working on. And everything was good.

Then as time elapsed the business rules started to do what business rules do – change and get more complex. Slowly untestable logic started to appear in the RowDataBound event of some of the GridViews. And upon these crumbling foundations further changes were made. Finally the customer asked for one change too many…and the whole house of cards came crumbling down.

After a significant amount of refactoring and painful business rule clarification with the customer I added over 10 focused classes, reduced the amount of overall code in this module by over 70% and created a a full suite of supporting tests / specifications that demonstrate exactly how everything should work. And there was much rejoicing.

The lesson here is that at some point in time any piece of your application might need some fairly radical surgery. There might not be an single large modification that highlights the need for rethink . Instead a succession of small changes can subversively undermine a once good design.

The key is always to look critically at the bigger picture when making a change. Beware of the the 5 minute change. It might take 5 minutes to make the change but without due consideration the impact to the overall quality of the application can start to adversely affect future development. And in this case I can pretty much guarantee that the changes made over the past 6 months were significantly slower and more dangerous because of the narrow focus of their predecessors.