Accelerate
This book goes into depth on research that shows how DevOps techniques can make technology organizations more effective. Fundamentally, they can help create generative team cultures which in turn leads to higher performance, better retention and better outcomes. The book shares multiple years of research from the State of DevOps reports.
Stats for nerds
31recommend
41mentions
38people
2018–2026years
78% recommend20% neutral2% critical
Mentions per year
What Hacker News says
- I think unfortunately the conclusion here is a bit backwards; de-risking deployments by improving testing and organisational properties is important, but is not the only approach that works.
The author notes that there appears to be a fixed number of changes per deployment and that it is hard to increase - I think the 'Reversie Thinkie' here (as the author puts it) is actually to decrease the number of changes per deployment.
The reason those meetings exist is because of risk! The more changes in a deployment, the higher the risk that one of them is going to introduce a bug or operational issue. By deploying small changes often, you get deliver value much sooner and fail smaller.
Combine this with techniques such as canarying and gradual rollout, and you enter a world where deployments are no longer flipping a switch and either breaking or not breaking - you get to turn outages into degradations.
This approach is corroborated by the DORA research[0], and covered well in Accelerate[1]. It also features centrally in The Phoenix Project[2] and its spiritual ancestor, The Goal[3].
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
- Sure, waterfall might work for very small fixed contexts. Control software for a spacecraft is a great example. I can sit down now and start designing software to do physical calculations for a system that won't ship for 7+ years, confident the laws of physics won't change in that time. In fact, NASA did this in the Apollo program.
Most software is used by customers with changing needs and competitive pulls. I've built software in the last 2 years that we would have taken a radically different approach to if LLMs were available, because they're great at summarising natural language. But they weren't. Imagine if we'd been building something for 2 years and never learned anything about changing technology or customer expectations - instead we shipped something fast, and then looked back after we learned about new things and made it better. That's how the World should work, and why software is not like building a bridge or a house or basically anything else in the history of engineering.
As to your specific exampleS: I have some detailed knowledge of hospital EHR systems, and they are so massively, hilariously broken in ways that modern software practices could easily help address. I suggest reading Accelerate [1] for data and examples of how agile applied to DevOps practice in particular means you can be more responsive and produce safer software, especially in that context.
I, like you, also prefer software for stuff that matters. I've been trained in formal methods, I've done embedded systems development, I've worked in medical/healthcare contexts. Your statement that what I've written above does not apply to those environments (including the use of formal verification methods), doesn't make sense to me.
[1] https://www.amazon.com/Accelerate-Software-Performing-Techno...
- OP here. Thank you for the kind remarks. Apologies because I can speak only in generalities; the devil is always in the details. As such this opinion, not prescription.
I read your description as working through a conundrum of priorities, goals, and outcomes.
Perhaps the way is to not get stuck in the weeds of either machines or computers.
What outcome(s) matter for the overall system? What measures make sense in service of achieving those outcomes? How will people get feedback about progress in service of the outcomes?
I am not suggesting some transplanted management framework (OKRs, I'm looking at you). Rather wondering about the small set of things you can get everyone to buy into and work towards. Decision making should become more tractable --- do the magic numbers even matter in the big picture? They may, if you desire to stay within a certain failure rate and/or error bounds, and it turns out the magic numbers are part of the problem. A thing like this won't be obvious in the beginning, you will to investigate things. Being able to say "hey, our stuff is failing at X rate and it is hurting our product/business in A, B, C ways" should help negotiate with management for the time / resource budget. Sometimes it may not be worth it, and so it may be wiser to drop that battle and focus on other outcomes. The investigation ought to be useful later.
I noted Gene Kim's initiative [1] in my post (no affiliation). I feel like that collection of resources will give you much to work with. If you had to pick one of those, I would recommend the Accelerate [2] book.
And, if you wish to talk about any of it, I'm happy to discuss more: https://www.evalapply.org/index.html#standing-invitation
[1] https://itrevolution.com/the-idealcast-podcast/ [2] https://itrevolution.com/product/accelerate/
(edit: expand on the main part of the response)
- It's more about engineering management but 'Accelerate: Building and Scaling High Performing Technology Organizations' by Nicole Forsgren (Github VP), Jez Humble and Gene Kim is a must-read.
- We, as an industry, didn't stop shipping bugs. (Small example: https://github.com/CVEProject/cvelistV5/releases)
And that thorough code review prevents bugs is, at best, a debatable assertion. See e.g. https://www.microsoft.com/en-us/research/publication/code-re...
It finds _some_ bugs. CI/CD, and a massive investment in automated testing has probably had the largest impact in moving software quality forward. (See e.g. "Accelerate", Forsgren, Humble & Kim)
Code review is an excellent tool to socialize knowledge and train up more junior engineers, but in terms of preventing bugs, it's low-value.
Related
Software architecture
1 recommend · 6
2017–2019
Continuous Delivery and DevOps
2 recommend · 3
Accelerated C++
47 recommend · 70
Do more faster
14 recommend · 27
The Phoenix Project
166 recommend · 340
Lean Software Development
6 recommend · 16
The DevOps handbook
22 recommend · 52
