Apr 25

Rules for Operations

The following list was compiled in 2012 for a talk on Operations Principles for Developers (Ops4Devs). They are loosely inspired by the list of rules from Zombieland as well as from my experiences and those shared by others. Looking over the list four years later, I believe that they are still (very) applicable for all of IT.

  1. Exercise your environment
  2. Test
  3. Beware of Assumptions
  4. Monitors
  5. Be a smart reporter
  6. Thread dumps are not proper error logs
  7. Just Enough Programming
  8. Get kickass partners
  9. Automate
  10. Eat well
  11. Get enough sleep
  12. Ask the Five Questions (Who, What, When, Where, Why)
  13. Manage Change
  14. Have repeatable processes
  15. Log
  16. Eliminate Pain
  17. Don’t be a hero
  18. KISS
  19. Eat your dogfood
  20. Reuse, Reduce, Recycle
  21. Dev be not proud.
  22. When in doubt, know your layout
  23. Don’t reinvent the wheel
  24. Be curious
  25. Document
  26. Follow the Principle of Least Astonishment
  27. Prod should mirror Pre-Prod (and vice-versa)
  28. Understandable error messages
  29. The buddy system
  30. Find a fix; don’t fix blame
  31. Know your data flows
  32. Enjoy the little things
  33. Swiss Army Knife
  34. Clean tests
  35. Stability
  36. Be Flexible
  37. More is not usually the solution
  38. If you don’t have time to do it right, you better have time to do it over.
  39. Assume your code will outlive you
  40. Do not use a hammer
  41. Report the right data to the right person
  42. Don’t Panic
  43. All programmers are optimists
  44. Check your code first
  45. Maintenance Driven Development
  46. Test again
  47. Don’t ask leading questions
  48. Shave with Occam
  49. Version Control
  50. Always have a backup
  51. Check Permissions
  52. You’re not in a Barnyard: Avoid the Stinky
  53. Load, Fire, Aim
  54. Try the Easy Fix First
  55. Have fun

The Big Three

(almost everything falls under these)

The Big Three


  1. NT

    What on earth does 8) and 19) mean. One assumes that is must have a meaning but at the moment I cannot see one…especially the dogfood one….sounds rather disgusting.

  2. Matt Williams

    Eating your own dogfood refers to using your own software and/or product/service. The phrase is believed to come from Microsoft — see https://en.wikipedia.org/wiki/Eating_your_own_dog_food for more details.

    As for #8, it’s actually taken originally from a set of rules in the Zombieland movie. The idea is that you want to have as good a team as possible. Also there’s the idea that you don’t want to always be the smartest person on your team — it’s hard to learn and grow if you’re the smartest one……

  3. NT

    Thanks, I am now informed. The dogfood – even if from Microsoft – still sounds really bad.
    Not an expression I want to use.

Leave a Reply

%d bloggers like this: