Software engineering practices
A selection of software engineering practices, from notes I took at an XTC meetup many years ago. They have survived the test of time very well. Practices change much slower than tools, and are typically a better investment.
- Keep your methods short.
- System should always be running – this means you need either live upgrades or a cluster.
- Always have a goal in mind – visible task. For example keep you current task on an index card stuck to the side of your monitor.
- Code should express intent – self documenting code.
- Verbose test names – Think of test methods names as a sentence.
- The code is the design.
- Do not duplicate code, effort, anything.
- Twice is a smell, three times is a pattern.
- No broken windows. Fight entropy.
- Check everything into source control. Tools, libraries, documentation, everything.
- Separate things that change.
- Write pseudo code first and keep it as comments if it is still useful. OR, write pseudo code as methods and then flesh out.
- Code for the common case – focus on building functionality that is the most useful first. 80% value for 20% effort.
- Text is king.
- Have courage – don’t talk instead of doing – resolve design debates by implementing the alternatives.
- Take a break.
- Proceed in small steps / small iterations.
- Understand the domain. Better domain understanding lowers communication cost and means you can use vaguer specifications.
- Make it work, then make it right, then make it fast.
- Strive for a coherent abstraction – does each ‘unit’ fit together.
- Open black boxes – look into bits of legacy systems you don’t know.
- Automate.
- Avoid ‘Manager’ objects – instead make them more specific: Retriever, Calculator, Finder, etc.
- Think in terms of interfaces, of behaviour, not of data.
- No magic: No wizards.