The Software Commandments
We aim to be great at software design and development, and to help improve the practice of software engineering as a real engineering discipline. We have learned that this can only be achieved by sharing what we know, and absorbing what others can teach us.
The Software Commandments help to guide the work we do.
- Commit to deliver, to help, to learn, and to improve
- Be honest, be reliable, work hard. But work smart too – minimise loop time on repeating tasks
- 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, keep asking til you’re answered
- Communicate! Keep colleagues and clients 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!
- K I S S – simplicity is ALWAYS an objective – for ui, code, design, test, process, delivery, documentation
- Think for yourself: challenge bad decisions, escalate if necessary – stay calm and polite
- Make sure you really understand the project objectives/targets, from the customer and user p.o.v.
- Keep a log (paper or digital) and use it every day
- Always keep your own backups, and make sure you can restore
- Code LESS: every line creates a work-chain. Code is a liability, not an asset
- 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, (work-in-progress too, at least daily). 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
- 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 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!