When I wrote about the Broken Window Fallacy in Software Development a while back, it appears that there were a number of misunderstandings.
- First, there is a fundamental difference between the economic Broken Window Fallacy and the "ghetto-ization" that comes along with the sociological/psychological aspects of the Broken Windows Phenomenon. I've already covered that difference.
- Second – and much more importantly – that doesn't mean you should never rebuild something!
I simply believe that you should be selective in your choices.. Every day you spend rebuilding something that works is one day that your competition has to catch up or get ahead.
That said, there are a number of times where rebuilding might make sense… but consider it carefully. Before you do anything else, just STOP. Don't go any farther until you ask yourself one question: "What's the goal here?"
Hidden in that question are quite a few others… What are you trying to do? What problems are you trying to solve? Is the code a mess and you want to clean it up? Is the fundamental structure just wrong and needs fixing?
My personal goal in all software development is to leave the code in better shape than I found it. That might mean removing unused stuff or simplifying things or improving/patching things. But at some point, it just gets to be too much and needs to be trashed… wha?
Yes, throw away your code!
No, not all of it. This goes back to my presentation from ZendCon last fall – The Bionic App. Odds are there are specific modules or functions that are the core of your problems. They're not just the core of your problems, they're probably also complex, buggy, painful to maintain and just plain cumbersome.
At some point, it gets to be a net loss supporting this code… so don't.