The Software Commandments V2.0

Codethink aims to follow these rules of engagement while complying with customer methodologies and practices:

General

Commit to deliver, to help, to learn, and to improve.
Be honest, be reliable, and work hard.
When you mess up, own up.
Don't stay stuck, get help. If you're in a hole, stop digging. If in doubt, ask - and keep asking.
Communicate! Keep people 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.
Clean and document as you go: don't leave a mess in the bathroom, the kitchen or your code.
Think for yourself: challenge bad decisions, escalate if necessary - stay calm and polite.
Make sure you *really* understand the objectives/target of the project.
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.
Get someone to review your code. Learn from the reviews, don't take it personally.
Use version control - ideally GIT. Commit early, commit often, with descriptive comments.
Quality code WORKS! All the time.
The bug stops here! Be responsible for testing and fixing your own code.
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!

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 mean garbage out!
Design must be communicated clearly in writing.
The first idea isn't necessarily best: consider alternatives, discuss.
Great design (and leadership) is methodology-independent.
K I S S. Avoid any complex approach which will not be easily understood by later coders.

When estimating, 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 your estimate includes, and what it excludes. And state that an estimate is 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 fairly and effectively.
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 you'll be late/low quality/over budget.

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