Skip to content

devcurmudgeon/software_commandments

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

28 Commits
 
 

Repository files navigation

THE SOFTWARE COMMANDMENTS

GENERAL

  • 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, 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!
  • 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

CODING

  • 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

TESTING

  • 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
  • Use a test suite. Know when to add, replace or remove tests when the codebase changes
  • If someone else finds a bug after you’ve said it works, kick yourself and improve your practice!

DESIGN

  • 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

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's included, what's excluded. State that it's a GUESS
  • Don’t be over-optimistic. It’s ALWAYS worse than you think

MANAGING

  • 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...

© Paul Sherwood (et al) 1996 - now

Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Packages

No packages published