One thing wrong with the software industry.

This is a post I have wanted to write a long time. This will be an article about what is so depressing about the craft of creating computer software and hopefully I'll be writing a few more of these articles.

The thing is that I know the secrets of why so many software projects just fail. Well they aren't exactly secrets, they are more like lessons that many people in positions to make decisions about software development just don't learn. If they where secrets, I would be a billionaire by now with a streak of successful projects behind me.

Lesson one: Artificial deadlines, milestones, timelines or time related whatever that is way too short, have a habit of biting you in the ass in the end. This is the most costly mistake that many companies do. Examples of this practice is: "This can't possibly take more than a couple of hours!" or "This must be done in x months, or the company must close up shop!". If a developer or developer manager buys into this then the impending train-wreck is almost always is a fact.

The single most important reason why it is a train-wreck just waiting to happen is that: Developers under stress is almost always more prone to produce low quality code. It could be possible that the code that was produced under pressure actually works, sort of. Lets say that it produces the desirable result. Of course there are a few bugs, but those get fixed... no big wreck that I warned you of earlier. This is a possible outcome, also in my experience not too uncommon. So where is the train-wreck?

It is in the maintenance phase of your application. All of a sudden when you have stressed out code it lacks some things like uhm... design because there was no time, comments because the developer that was under stress thought "I'll fill in that later, after the project is shipped and done!" and the next crisis surfaced(it was those pesky bugreports that poured in!).

The psychology behind the keyboard that produces this is that with an artificial timeline/deadline it is treated like a 100 m dash instead of a marathon. This is the important thing, when you impose stress on a developer he will code like there is no tomorrow and the result has no tomorrow either. He expends all his energy on the very beginning of the race and just codes away without thinking of the rest of it. What happens if the bug that surfaces six months after delivery and it turns out that it is a huge design flaw? There is no simple way of "patching" it, it takes a lot of time and money. What happens if the feature request that come in after one month is crucial for your customer/customers and it doesn't fit in your design without rewriting significant portions of the code? Same result. You might lose the customer(s), because they lack patience and/or find a cheaper vendor that (can) provide what they want. That is expensive isn't it. That is the wreck in all its glory...

This was an entry inspired by parts of this article.