Of course Uncle Bob would say that because it serves his purpose of selling the Clean Code-book, but I would still agree with him on this one. I often hear a lot of programmers complaining that in a world of perpetual recurring short deadlines there will be a lot of technical debt and code debt in our line of work. Unfortunately.

But what can we do about it? There is never time for a spring cleaning and the business usually can’t see the point of such an activity, but hey, they are not the ones having to live in that messed up codebase.

Sometimes I even hear the technical debt argument as a anti-agile argument – because an organic not-designed-up-front architecture is inevitably going to end up with a lot of technical debt IF NOT REFACTORED on a regular basis. My answer to that, is that refactoring is a part of any agile programmers job – your story is not finished before you have refactored the code and considering architectural refactoring should be part of sprint planning.

A similar point is made by Uncle Bob in this video from the IT-conference JAOO (about 7 minutes in);
When Uncle Bob asks Pete McBreen how a programmer can get the time to write good code and his answer is: “you should cheat the boss – just write good code without permission to use the time”, Uncle Bob comments, that he doesn’t consider that cheating – he considers that professionalism!

I still believe that an organic REFACTORED architecture is better than an up-front-planned architecture, that is outdated and worked around when adding new features.

Is your work also impeded by bad code? Do you consider it professionalism to cheat your way to a liveable codebase?

P.S. Michael Feathers (also in the video) just wrote a blog post about learning from bad code. Please consider helping him with this project.