Jump to Comments

When building something new, mistakes are unavoidable. To paraphrase the common saying, “if you’re not making any mistakes, you’re not trying hard enough”. There’s another saying which says that the difference between a good carpenter and a bad carpenter is not that the good carpenter doesn’t make any mistakes, but that he’s better at turning them into masterstrokes. You can, and should, try to prevent mistakes from happening, but it’s a fact of project life that things go wrong.

Many books can be filled on the subject of how to deal with the huge variety of project mishaps. In this article, I’ll focus on one specific type of mistake: the big, fundamental mistake.

There are some mistakes which scare the living hell out of you when you find out about them. They’re basic, they’re fundamental. They’ve got “killer” written all over them. Here are some examples:

• choosing the wrong platform or framework to develop your product
• building on critically flawed code in the hope that it will improve over time (it won’t)
• missing or misunderstanding a major, crucial requirement

When you come face to face with one of these, the natural tendency is denial. You might first try to ignore it or downplay it. “It’s not that big a deal”, “we’ll deal with it on the side”, “the world/plan still goes on”, “we can change it later”.

It takes a great deal of courage to say “we’ve made a fundamental mistake and we need to fix it right now” when one of those issues crop up, particularly in blame-driven environments where the primary reaction to mistakes is to look for someone to blame.

The reason why it needs to be fixed right now is that the really big damage from these issues continues to come after they’ve been raised. This is why you need to assess the damage and make the decision to fix it as soon as possible. Critical issues that are swept under the carpet grow bigger every day.

Here are two examples to illustrate both possible outcomes.

The applet story

I once worked on a Struts application, in a bank. A major component of it was an applet. It was badly designed to begin with, being the product of a summer intern’s prototyping efforts, yet it was considered to be “80% finished”. Since a whole summer of cheap labour had already gone into it, the consensus was that it just needed to be finished with a couple of week’s work from a qualified senior engineer. So a senior software engineer was set to the task. Then a junior software engineer was thrown in. The applet grew, like a cancer. By the time the senior engineer “fell ill” and then quit, the applet had several hundred classes. By the time, a year later, the senior architect on the project finally found it politically acceptable to propose a complete rewrite of the applet, it had grown to over a thousand classes, and had swallowed over a man year of pure development effort (with even more QA and overhead time).

What happened then? The whole thing was rewritten in under a month, and went from over a thousand classes to about twenty. It ran faster, was less buggy, and was clean and easy to maintain.

Now, to be fair, the project manager didn’t know that the applet was quite so bad when he took on the project. He also joined the project a couple of months after it started, so he was not in an ideal position to kill the rotten half the project immediately, particularly since he was an external consultant. Truth is, the entire project (and I was a part of it) was responsible. Yet even though everyone knew the applet was a black hole for time and resources, the solution to this critical problem was always pushed back to “after the go-live”, because it was not politically acceptable to admit we made that big a mistake.

This is the kind of mistake a huge international banking corporation can absorb and not even notice it. What’s a few hundred thousand pounds wasted here or there when your quarterly profits are about 9 billion dollars? If this happens to your startup, though, you’re toast.

The Flex story

As a contrasting example, on another project (this one in a startup environment), we initially put in two solid weeks of very productive work building the application using Flex and the popular Cairngorm framework. In that time we followed the Agile mantras and delivered some great user-visible functionality. Everyone was quite excited about the pace of development. There were good feelings all around.

Then, our Flex developer told me that he didn’t feel Cairngorm was well suited for the kind of complex RIA we were building, and that he was going to work, “on the side”, on porting the functionality over to PureMVC.

When he casually pointed that out one day during an informal chat, alarm bells went off in my head. It would have been very easy to accept the proposal that we’d be working on this on the side and continue onwards, building the application with Cairngorm until the PureMVC port gave its fruits. But it would have been the wrong choice.

Instead, after discussing in earnest whether the limitations of Cairngorm really warranted such a major change of framework (they did), we put all the “new functionality” work on hold and did all the porting work right away. Result? It took us two weeks to finish the port (predictably, it took just as long as we’d spent building the functionality the first time around). If we had waited any longer, it would have taken more time. If we had waited long enough, the switch would have become too costly and we would have had to stick it out with an inappropriate framework. This would have increased out long-term costs by making it significantly more difficult to make changes.

This was a hard choice. It killed our momentum for two weeks, and in a different environment this may have been politically unacceptable, even so close to the beginning of the project. But it was the right choice, and making it quickly saved us time and money.

Conclusion

When you’re faced with a big project mistake, deal with it now, even if it’s going to cost you. Spending more time and effort going in the wrong direction is like throwing good money after bad. Don’t freak out, stay calm and make rational, measured decisions - but don’t assume that the mistake can be fixed more easily later. Instead, always assume that every day that you wait before acting to fix it will add another day to the cost of the fix itself.

If, during the discussions, you find that the mistake is not really critical and that it can be fixed later, go for it - but always ascertain that for yourself rather than assuming it.

Thank you for reading. As always, any comments and contributions are most welcome.