The Software Commandments
- Commit to deliver, to help, to learn, and to improve
- Be honest, be reliable, and work hard
- When you mess up, own up! And LEARN from your mistakes
- Don't stay stuck, get help! If you're in a hole, stop digging. If in doubt, ask. Keep asking til you're answered
- Communicate! Keep colleagues and customers informed - avoid surprises
- Write effectively, speak effectively - keep it short and make it matter to the recipients
- Finish your project. Know your deadlines, hit them if you can, shout if you realize you can't
- Solve problems, and help others to solve problems too – everyone learns faster that way
- Never leave a mess behind you: this applies to your project, the kitchen AND the bathroom!
- Think for yourself: challenge bad decisions, escalate if necessary - stay calm and polite
- Make sure you *really* understand the objectives/target of the project, from your customer's point of view
- Keep a log book and use it every day
- Always keep your own backups, and make sure you can restore
- Code LESS: every line creates a work-chain
- Read the documentation, use existing code if possible. Don't re-create what already exists
- If there isn’t a spec/definition, write a short one (with constraints, goals, non-goals) and agree it
- If it isn’t specified as a requirement, don't code it. If the agreed spec is wrong, challenge it
- Understand why code style is important, and comply with existing style
- Get someone to review your code. Learn from the reviews, don't take it personally
- Use version control, ideally Git. Commit early and often, with descriptive comments, and push your commits!
- Quality code WORKS! All the time
- The bug stops here! You are responsible for testing and fixing every line of code you write
- Remove uncertainty as fast as possible. Prototype, learn and iterate
- Set yourself doable targets every day and every week. If you're not making daily progress, shout
- Test behaviour, not structure. Don’t be gentle, break it!
- Write down what you need to test before or at the same time as you write the code
- Look for difficult, unexpected cases too
- If it can’t be tested, it shouldn’t be there
- If there's a test framework, use it. Aggressively replace/remove tests when things change
- If someone else finds a bug after you’ve said it works, kick yourself and improve your practice!
- Establish constraints and write them down
- Plan to remove uncertainty fast - prototype and test against realistic scenarios ASAP
- Design for testability, and design defensively: garbage in DOES NOT equal garbage out!
- Design should be communicated clearly in writing, pictures or both
- The first idea isn’t necessarily best: consider alternatives, discuss
- Great design (and leadership) is methodology-independent
- K I S S - simplicity is ALWAYS a design objective
- Discuss the requirement with others – get perspective
- If you’re unsure, say so. If you need more information, ask for it
- Break the problem down into component tasks – get someone to challenge the breakdown
- Compare like-for-like: try to check against previous productivity on similar work
- Estimate the whole job, not just the coding. State what's included, what's excluded. State that it's a GUESS
- Don’t be over-optimistic. It’s ALWAYS worse than you think
- Get the best people you can find/afford, and clear the way so they can be effective
- Provide strong leadership – make sure your people know what they need to do, and when
- Allow and foster open and honest communication. Listen and learn. React effectively and fairly
- Encourage debate where necessary, but if things get bogged down, be a benevolent dictator
- Set short timescales for targets and reviews – weekly is probably best
- If you're squeezed on time and cost, reduce scope – or it'll be late/broken/over budget
- Nail the risks, before they nail you!
In case things still don't work out after all of the above, keep making friends...