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