Date: 24 January, 2008 - 08:52
After my post last week on "The Broken Window Fallacy in Software", it was clear that there was a misunderstanding. In terms of Broken Windows, there are two types..
First, there's the Broken Window Fallacy which is an economic explanation which dates back to the 1850's. The principle idea - which I was building upon - is the concept that economic activity of any form is good for the economy as a whole. This completely ignores the fact that there are costs - often hidden - under any circumstances.
In the case of the Broken Window (or the "let's start fresh!" idea of software development), the primary actor in the situation loses control of their decision. They don't have the option of using the time/money/effort for something else, they must use it to return to the previous status quo.
Food for thought... If someone broke your window, it would be vandalism... what should we call it in software development?
Second, there's the Fixing Broken Windows idea which has its roots in criminalogy and psychology. It is built on the basis that accepting/allowing lower standards will result in even lower standards being accepted later. In the original analysis/discussion, the idea was that once a building has a few broken windows which are allowed to persist, other things will happen.
The Pragmatic Programmers - Andy Hunt and Dave Thomas - were the first ones (in my knowledge) to apply this to software. As you let little hacks and nastiness exist in your code, more will follow until the entire system is a mess of one-off hacks and a nightmare to maintain.
A variation of the concept is "A players hire A's. B's players hire C's."
Actually, I think they're more related than I previously considered:
- Why do we accept it that software breaks on us?
- Why do we accept the idea that every piece of software has to be upgraded with every system upgrade?
- Why do we accept the little hacks and tweaks that make it work for now but are likely to cause problems later?
It appears to me that our standards and expectations have been lowered so far that in many cases, we're happy if the damned thing works right just once in a while... and the person who can swoop in and provide a one-off hack to fix the immediate problem is the hero.
Why is that?









Why is that?
Everyone likes to be a hero. Solving a short term critical issue is usually more interesting and adrenaline producing than producing code to a schedule and a feature list. Immediate feedback and praise are forthcoming instead of "Are you going to have release x done by Thursday?"
It could be a combination of
It could be a combination of effects. First, software is hard. That's why it breaks a lot. Second, there is a business rush put on everything to do with software because, by and large, the business only gets value out of the software when (1) it is done, and (2) it is working. These two effects together create a situation where the software is often breaking (or "sometimes working") and there is a high value put on "just getting it working *for now*." I emphasize the *for now* because often times companies are driven by short term profits (especially with investors looking over your shoulder) and thus having it working now but hacky is better than having it working later and well thought out and intelligently implemented.
Do I agree with this general mode of operation? No. Do I think this is happening in a lot of companies? Absolutely.
Post new comment