What’s Rule 1?

Over the years, I’ve found myself repeating some of these ideas to my teams. Here’s the superset. If you have some rule 1’s of your own, please drop them in the comments.


  • You’re only as good as your next gig – past success is no guarantee of future success
  • It’s easy to forget what makes you successful – you need to work hard to keep the skills/techniques that made you successful
  • It’s not necessarily what you first think it is – as you proceed in a project, you have to be prepared to rethink your initial assumptions, and embrace that
  • In a crisis, proceed calmly and with purpose – things will go wrong; taking a thoughtful and calm approach to them will fix them, rather than make them worse


  • It’s easy to do great work, easier to do bad work – the idea that quality is hard is ridiculous, but bad quality is always there for the taking
  • We care – if you commit and embrace the challenge and try to do your best, you’re always more successful and able to find and resolve the gaps
  • Don’t let your principles get in the way of success – perfect is the enemy of good, standing on principle for a small thing can lead to a destructive outcome; you can always refine initial solutions if they’re not 100% perfect
  • Don’t neglect your principles to give the illusion of success – you can be unsustainably, apparently successful for a short time if you drop your best practices, but nobody will thank you for it
  • No special pleasing/excuses – don’t try to make yourself look better when things go wrong, don’t shirk responsibility or say that things don’t apply to you, find the best answer
  • Don’t just do as you’re told – think, act thoughtfully, do what’s needed, not what’s written on the request
  • Don’t just build the architecture and expect it to work – architecture is a structure, it’s not necessarily perfect

Bridge the Gap

  • Give respect to earn trust – nobody trusts people who treat them poorly, building trust is more important than building software
  • You can’t argue with working software – demo something that’s a working increment and you can have a productive conversation about what to add/change
  • Don’t make them beg – your users/customers do not want to be faced with barriers when they ask you to do your job; help them get the result they need
  • The patient always lies – your users/customers are experts, but they need helping to tell you the whole picture
  • Be a fire boat – solve the whole problem, don’t draw a boundary and hide behind it – don’t be the fire brigade that doesn’t work at sea, or the lifeboat that can’t help with the flames


  • Step 1 – write a failing test – TDD all the way
  • Put quality first – a good small thing is better than a crap big thing
  • Fix it twice/make it work, then make it good – accept that the first working solution won’t be perfect and that you sometimes need to get things working before refining them
  • Don’t overmock your tests – mocking to death proves nothing

Make the Process Work

  • Don’t just copy another team’s process – and expect it to work for you the same
  • Use the agile rituals to achieve their purpose – don’t just pay homage to the Agile Gods
  • Stay near the edge of the forest – incremental and releasable
  • Build small, simple, things – big software is best composed from small simple pieces

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s