DevOps messes with your head - reprised

Last year I wrote about how DevOps messes with your head, or as we say down here, it does yer head in.

In the interim I have been adding more examples to the presentation which I shared.

Then recently I started a thread on Twitter with the hashtag #dmwyh. Unfortunately it has all fallen off Twitter.

So here for your delectation is my new improved list of examples of

How DevOps Messes With Your Head


  1. DevOps is undefined
  2. Less process (and the whole Agile Manifesto)
  3. Prioritise that which you can get done
  4. Limit work to get more done (stop starting and start finishing; do less to do more)
  5. It’s more important to improve work than to do work
  6. Unpredictable systems (complex systems; waterfall is a myth)
  7. Victims of the system; unreasonable systems make unreasonable people
  8. Experiment: suck it and see
  9. Fail small, fail early, fail often, fail fast (and embrace failure)
  10. Fail forward (rollback is a myth)
  11. Thank-you for failing (noble failure; failure is positive data; failure exposes weakness in systems; no blame)
  12. Planning is essential, plans are expendable
  13. Test in prod
  14. No projects
  15. Be mean to your code (randomly break it)
  16. Destroy environments regularly to increase reliability
  17. If it hurts do it more (until it doesn't)
  18. Get out of the way (don't control; facilitate)
  19. Maximise the work not done (make it as simple as possible but no simpler)
  20. Don’t do work too soon (it goes stale)
  21. Managers don’t know the answers (let the people who do the work design the work)
  22. Teams with no leaders or roles
  23. Infrastructure as code (metal to money in one package)
  24. Toolsmiths (we don't build prod; we build the tools to build prod)
  25. Servers are cattle not pets (slaughter them at will)
  26. Let Dev own Prod (shift accountability left)
  27. ChatOps
  28. Commit to Prod (untouched by human hand)
  29. Change Prod every 75 seconds.
  30. Release during work hours (when everybody is there)
  31. No branches to code, just trunk/master
  32. Write your tests so that the code fails
  33. Test Driven Design (the tests are the design spec)
  34. Stop making defects (fix time, money and quality; vary deliverables)
  35. Prioritise defects over new (when the production line breaks, stop everything)
  36. Going faster reduces risk
  37. Faster better AND cheaper
  38. IT can be a normal job (9 to 5)

Any more? I'll keep adding to it

Syndicate content