The Software Commandments


  1. Commit to deliver, to help, to learn, and to improve
  2. Be honest, be reliable, and work hard
  3. When you mess up, own up! And LEARN from your mistakes
  4. Don't stay stuck, get help! If you're in a hole, stop digging. If in doubt, ask. Keep asking til you're answered
  5. Communicate! Keep colleagues and customers informed - avoid surprises
  6. Write effectively, speak effectively - keep it short and make it matter to the recipients
  7. Finish your project. Know your deadlines, hit them if you can, shout if you realize you can't
  8. Solve problems, and help others to solve problems too – everyone learns faster that way
  9. Never leave a mess behind you: this applies to your project, the kitchen AND the bathroom!
  10. K I S S - simplicity is ALWAYS an objective - for ui, code, design, test, process, delivery, documentation
  11. Think for yourself: challenge bad decisions, escalate if necessary - stay calm and polite
  12. Make sure you *really* understand the objectives/target of the project, from your customer's point of view
  13. Keep a log (paper or digital) and use it every day
  14. Always keep your own backups, and make sure you can restore
  15. Coding

  16. Code LESS: every line creates a work-chain. Code is a liability, not an asset
  17. Read the documentation, use existing code if possible. Don't re-create what already exists
  18. If there isn’t a spec/definition, write a short one (with constraints, goals, non-goals) and agree it
  19. If it isn’t specified as a requirement, don't code it. If the agreed spec is wrong, challenge it
  20. Understand why code style is important, and comply with existing style
  21. Get someone to review your code. Learn from the reviews, don't take it personally
  22. Use version control, ideally Git. Commit early and often, with descriptive comments, and push your commits!
  23. Quality code WORKS! All the time
  24. The bug stops here! You are responsible for testing and fixing every line of code you write
  25. Remove uncertainty as fast as possible. Prototype, learn and iterate
  26. Set yourself doable targets every day and every week. If you're not making daily progress, shout
  27. Testing

  28. Test behaviour, not structure. Don’t be gentle, break it!
  29. Write down what you need to test before or at the same time as you write the code
  30. Look for difficult, unexpected cases too
  31. If it can’t be tested, it shouldn’t be there
  32. If there's a test framework, use it. Aggressively replace/remove tests when things change
  33. If someone else finds a bug after you’ve said it works, kick yourself and improve your practice!
  34. Design

  35. Establish constraints and write them down
  36. Plan to remove uncertainty fast - prototype and test against realistic scenarios ASAP
  37. Design for testability, and design defensively: garbage in DOES NOT equal garbage out!
  38. Design should be communicated clearly in writing, pictures or both
  39. The first idea isn’t necessarily best: consider alternatives, discuss
  40. Great design (and leadership) is methodology-independent
  41. Estimating

  42. Discuss the requirement with others – get perspective
  43. If you’re unsure, say so. If you need more information, ask for it
  44. Break the problem down into component tasks – get someone to challenge the breakdown
  45. Compare like-for-like: try to check against previous productivity on similar work
  46. Estimate the whole job, not just the coding. State what's included, what's excluded. State that it's a GUESS
  47. Don’t be over-optimistic. It’s ALWAYS worse than you think
  48. Managing

  49. Get the best people you can find/afford, and clear the way so they can be effective
  50. Provide strong leadership – make sure your people know what they need to do, and when
  51. Allow and foster open and honest communication. Listen and learn. React effectively and fairly
  52. Encourage debate where necessary, but if things get bogged down, be a benevolent dictator
  53. Set short timescales for targets and reviews – weekly is probably best
  54. If you're squeezed on time and cost, reduce scope – or it'll be late/broken/over budget
  55. Nail the risks, before they nail you!

In case things still don't work out after all of the above, keep making friends...