One of the most awesome books I read last year was The Phoenix Project. It's a fiction (I hope) story that compares a lot of the aspects of software development with factory work. Some elements of LEAN are presented and applied to improve development workflows. I won't spoil too much about the story, in case you want to read it (and you should!).
A lot of the ideas presented in the book have evolved into the best practices we know today. But what is the motivation behind these best practices, why do they exist like they do?
Finding your constraint
The book talks in detail about the idea of constraints. It draws parallels between software development and manufacturing that make a lot of sense. A constraint at a factory would be that part of the factory where items take the longest to be processed. This includes both the wait time and the processing time itself. The constraint is what determines the actual output of the whole factory. The book boldly states that any improvement you make that doesn't improve the constraint is a wasted effort.
What do you wait for most in your daily work? What blocks or slows down features from being available to customers? Improving processing time might be hard for most things. On the other hand, improving wait time is often relatively easy.
You can stretch this idea to a really small scale. For example, the time you have to wait for someone to review your change. Analyzing how you or your team spends time this way can give you a lot of ideas to improve your process.
Reducing hand-offs
Best practice: Let developers do everything needed to build and run an application (i.e. DevOps)
In traditional companies, there are often multiple departments that are all involved in getting a single feature live. Think for example of QA, security or deployment departments. Delivering a feature in such a company means that you'll have to hand-off the feature multiple times. But these hand-offs are expensive and error-prone. And any of these departments may have different priorities, resulting in long waiting times.
DevOps then is not so much about combining dev and ops responsibilities, as it is about allowing one team to deliver a feature by themselves. One team, or even one person, takes care of building a feature, testing it, verifying if it complies with set security standards, anything that is needed to deliver. This can increase throughput because of reduced wait times. And it can also reduce finger pointing, because you as a developer are and feel responsible for application or feature as a whole.
Automated deployments
Best practice: Deploying should be easy, one-click if possible
A place in the feature pipeline that is often the constraint is the deployment of features. The book talks in depth about the value of being able to automatically deploy changes. If you're not able to deploy automatically, changes are likely to stack up and then be deployed in batches. Deploying a batch of changes is inherently more risky. Add to that the human error that the manual aspect introduces, and you've got something quite scary. The book paints a really vivid picture of some deployment scenario's that you'd rather not be in.
Getting stuff done
Best practice: Keep work in progress to a minimum
Imagine you work at a factory and you have 5 items to work on. Each item takes an hour to finish, and it consists of multiple steps to complete. If you start work on all 5 at the same time and finish each step completely before continuing with the next step, after 5 hours all items are done. You might actually finish slightly faster because you're doing things in bulk.
If you instead work on the items one by one, doing all the steps for a single items, it will still take 5 hours to complete all, but the first item will already be done after 1 hour. This of course applies in the same way to any task you work on as a developer. However, the bulk advantage doesn't really exist for us developers. It's actually slightly worse because the cost of context switching when you work on multiple things at the same time.
This may seem trivial, but it's really easy to get wrong. There's always someone who depends on you getting stuff done. If it's not a colleague, it's probably a customer. Reducing the time it takes to get stuff done, will make sure your customers get new features earlier. And because they get those features earlier, you will get feedback earlier.
Conclusion
DevOps and the ideas it contains have existed for some time now. Diving into the foundational concepts behind it has given me a whole different look on the way teams should be setup and function in a company. You're not taking advantage of all these ideas if your DevOps people still have to wait for someone to test their work, or for someone from security to give stamp of approval. That doesn't mean that you shouldn't test or build secure stuff. Rather it means that these responsibilities shift towards a single team.
The book does a great job at explaining all these ideas and linking them together. It's a really fun and easy read, I would definitely recommend you check it out.
Top comments (1)
It’s my fav book.
Really good!