Software Development Laws - Learnt Through Experience

I like writing software. It is great to be able to see the computer do something amazing that you invented through code. It is why I'm not surprised Donald Knuth called his famous book series The Art of Computer Programming. Writing, or crafting, code is artistic, most of the time. However, I've spent enough time writing programs for businesses to have some laws that seem to apply to most paid software projects. If you are a long-suffering software developer you may recognise these laws:

1. Assume the user of the software is a child. - The software needs to be so simple and clear that people can use it without barely thinking. They never RTFM (read the flaming manual).
2. If the customer is not the user, the specification will have errors. - Software projects specified by the managers of the users, or consultants brought into a company, are painful. The final customer or end user needs to be involved from the very beginning. They know how the process works and how the software needs to work. Is that why history is littered with failed software projects?
3. Only add program features to meet the specification. - Never assume that a feature is needed. Coding is your valuable time, and your time is being paid to meet the specification and only the specification. I've seen too many projects become late or fail due to extra features that were not required or requested. Only produce what you are paid to produce. Extra software means more testing and more cost, eating into profit.
4. Your code will have bugs, test your code, but your code will still have bugs. - Any software of a decent size will have bugs. Code must be tested. Test-driven development is a great habit to get into. On many projects I've been involved with, developers who failed to test code caused all sorts of issues further down the development and release cycle. Yes, bugs always seem to exist, because software is complex, but test your code. It helps make projects profitable.
5. Release early and release often. - Building and releasing quickly should be automatically set up. Great DevOps helps to push out releases to customers who can provide quick feedback. Agile development works well for successful software.
6. Get sign-off and get paid. - As soon as the customer is happy that the software meets the specification get the evidence with a formal agreement. Then you can get paid. Too many times developers agree to do tweaks and interface changes before getting sign-off and end up with poor cash flow. The agreed specification is the contract. If it meets the specification get paid. Tweaks and changes are extra.
7. Software is never finished, it does just enough, now goto 1. - Software, just like a painting, is never finished. It can always be added to or changed, so stop when you can. If it does what is required it's time to move on to the next project. Remember, time is money.

See Also

• Here are some other Famous Laws of Software Development
• For a list of all the articles in Tek Eye see the full site Index