Each of these mistakes has cost me, and my employer, dearly. Please learn from my mistakes.

1. Not testing the small stuff

If it is complicated enough where you could make a mistake, it might be worth taking the extra effort to test it. Necessarily, not every single line can (and should be) tested - because to do so would make it too cumbersome to progress rapidly, but you need enough coverage to have confidence that things aren’t going to break. The problem, is that if your coverage is too scant, there might be a bug that is very difficult to track down. Save yourself headaches down the line. If it is complicated enough: then test it. I must have lost about 90 minutes tracking down something which I had a vaguely inclination should be unit-tested, but overlooked it in favour of a test with a larger coverage. That’s 90 minutes I’ll never get back.

2. Start Simple

There’s nothing worse than building a complicated piece of machinery, which nobody wants to use. Start simply, get the product in your user’s hands, and then progress. I’ve lost 8 days, building something that my end users rejected, when a simpler but less comprehensive solution would have sufficed.

Lesson learned: start simple, and get it into your users hands. The later you delay it, the greater than chance of a momumental cock up.

Unless you work for a government department, or are a politician (with the infinite resources of tax payers to burn), we do not have that luxury.

3. Put your foot down - Solve The Real Problem

Your client has a vague idea of what he wants. He might want windows on his submarine. In fact he might insist on it. Here, he is locking you into an implementation of a particular perceived problem. Your job is to work out what his real problem is, and to supply the apposite solution. Simply thinking that your client is God, meaning that you are to follow his orders without thought, is a sure-fire recipe for disaster: for both yourself and him. Put your foot down and object. Fight for an implementation that will solve the real problem, and save your client money, and most importantly: time.

I’ve cocked this up. I used to simply blindly follow what the client wanted. Not anymore.

4. Estimate Cost(s) and Time Upfront

This is a nebulous task. Clients want to know what things cost (up-front) without knowing what they want, and without knowing how to solve the problem at hand.

The most important thing you can do is to make the client understand how software is done. To plan every inch in advance, to spend 1-2 years doing so, and to expect it to work is pure folly: but this is how uncle Sam does things, and it is precisely why the US Government manages to squander hundreds of millions of tax payer dollars on boondoggle projects (e.g. Virtual Case File) that go nowhere. Building software necessarily involves actively managing the scope of the task at hand, business insights and ingenuity, as well as creativity; in addition to understanding and solving problems.

What you absolutely do not want to do is to promise to build “a website” for a client, with a scope that is very vague, and with a fixed price in mind. Then they might ask you to build Google within 2 weeks, for a sum that is not feasible.

Key elements:

• Solve the problems by limiting the scope.
• Clearly spell out deliverables.
• Deliver to that, at the specified price.
• Allow for the possibility of changing the scope if possible.