The science of lean software and DevOps
This book is less so focus on technical design details and is more about the philosophy about how well-run generative organizations can have a measurable and positive impact on software delivery and performance which ultimately results in improvements in business objectives such as:
- Profitability
- Productivity
- Market share
Much of the concepts discussed in this book are things that are almost taken for granted in 2026 (given that this book was released in March of 2018). This includes things like:
- Automated build processes
- Automated test suites
- Agile development
- There is a dedicated chapter in this book for exploring the applications of what a generative organization looks like in ING bank in the Netherlands, which seems like honestly a primitive implementation of how we use agile today. More on this later.
- Organizational culture where failures are learned from and not feared
There are nuisances to this however. Automated test suites contain a lot of slop. Especially now with AI. With unit tests, this matters less, but integration and end-to-end tests should stay lean and essential. Unit tests should be written deliberately and not out of obligation. There is almost a security theatre with automated testing. Agile development is along the same lines of working well when done right. The idea of providing visibility into what others are working on is a good one, and stand-ups are great for discussing and resolving blockers. However, in instances where everything is smooth, standup contributes to time fragmentation, decreasing my personal productivity. There is also sometimes theatrics around agile rituals. Throughout my co-ops + my introduction to new grad life, I’ve never felt like I would be penalized or the “messenger would be shot” if I brought up a system shortcoming, or even made a mistake. I think this shines an interesting perspective about the growth of software organizations over time.
Important learnings that I did get out of this book include:
- Left shifting on security
- Team experimentation (20% time)
- Reducing employee loyalty, retention, and burn out through reduced workload and mental load
- Testing should not rely on an integrated environment
Often times workflows are much more productive when you initially design around all of your requirements, where software security is an important requirements. Design with security in mind instead of having to retroactively include security in designs. I think 20% time is a great way to keep employees happy by allowing them to work on what they think is interesting as well as foster innovation within an organization. Workload directly drives employee burn-out. I could feel this through time pressures within my own experience. We want to reduce workload and cognitive load by automating repetition and things that machines are good at (and that humans are directly bad at) to reduce burn-out.