Three great business reads for programmers

The Goal

What could a physicist possibly have to say about the business of manufacturing? Manufacturing is a long way from the ivory tower. Let’s find out from physicist and business consultant Elihu Goldratt.

First a bit of back story. My father was a systems analyst for most of his career, a sort of internal-tools product manager who developed and improved manufacturing automation. He wrote a fair bit of COBOL. I noticed this book, The Goal, during a visit home, some time in the mid-1980s. While a career in business was the farthest thing from my mind at the time, I was intrigued by the premise, found it an easy read, and found the general principles applicable far beyond the shop floor.

Theory of Constraints

The Goal introduces the Theory of Constraints in the context of manufacturing: a system is only as fast as its slowest process. Improvements downstream don’t really matter, hence cost accounting for efficiencies can be misleading.

The main point of the book is to inspire industrial management to change thinking cost accounting, incorporate the Theory of Constraints into business planning, and use the following three precepts as a basis for business planning:

  1. Throughput is the rate at which the system generates money through sales.

  2. Inventory is all the money that the system has invested in purchasing things which it intends to sell.

  3. Operational expense is all the money the system spends in order to turn inventory into throughput.

Three simple notions accurately capturing the business of making stuff to sell. While not prescriptive, these precepts provide a framework for thinking about activities not in harmony with the goal. The goal, by the way, is explicitly discussed in the book, and we follow along with the protagonist as he discovers the goal for himself.

The Goal made a large splash when it was first published, and the ripples of the that splash continue to spread even today. The Theory of Constraints is widely applicable to many systems. While manufacturing and software have little in common at the low level, parallels emerge from comparing the bigger picture. Adapting these parallels to IT-driven companies is the focus The Phoenix Project, which will be reviewed next.

Recommendation

As it turns out, I only recommend The Goal with reservation. The author’s message is clear and relevant, but the social milieu and cultural mores may be alien or even repulsive to modern readers. Character development is stereotypical and weak, and the industrial concerns of the 60s, 70s, and 80s may not resonate with today’s technology-focused professionals. The narrative structure risks alienating such readers, early on in the book.

However, the reader willing to suspend judgement (smoking indoors! wat.) to extract the bigger picture will find the modest investment of reading time well worth the effort. Read at your own risk, and keep an open mind to understand the intended audience.

(Bonus: find the John Prine reference and dinner is on me.)

While not generally recommending The Goal, the review above is important to introduce a book which I highly recommend, The Phoenix Project.

The Phoenix Project

As Honor Harrington channels Horatio Hornblower, we next examine Gene Kim’s account of an IT infrastructure every bit as whacked as as manufacturing at Goldratt’s UniCo, as described in The Goal.

A few years ago, when I was working as a developer on a dog sled team (not the lead dog), The Phoenix Project made the rounds through the operations team. While I had nothing to do with operations (dog sled developer), it looked like an interesting read, and I was delighted to find the Theory of Constraints reappearing. Even more interesting, I could easily relate to many of the situations described in the book. We had our own “Brent” at that job (the lead dog).

The author’s area of expertise is in the operations side of information technology, that is, setting up servers, networking, application deployment and delivery, activities traditionally within the bailiwick of systems administrators. The move to large, distributed, cloud-based infrastructure has induced the “DevOps” movement, nascent in 2014 at the time of the book’s publication. DevOps is the notion that systems administrators should be automating infrastructure, and allowing developers to self-serve their day-to-day operational needs.

Again following The Goal, Kim asserts three overarching points control delivery of a software product:

  1. The First Way: understand how to create a fast flow of work moving from product into production, because that’s what’s between the business and the customer.

  2. The Second Way: shorten and amplify feedback loops, fix quality at the source to avoid rework.

  3. The Third Way: create a culture that simultaneously fosters experimentation, learns from failure, and understands that repetition and practice are the prerequisites to mastery.

These three “ways” neatly encapsulate principles against which daily activities can be evaluated. Activity promoting the any of the three ways will increase throughput in the system, throughput here meaning delivery, just as in The Goal.

There isn’t a lot in the book to quibble with. While the character development may be stereotypical, at least the ashtrays are gone. Thirty years from now our current mores may feel cringe-worthy, but this is now and than, and techniques promoted by the book can be implemented immediately.

Recommendation

I recommend, without reservation, The Phoenix Project to anyone relying on information technology services for any reason, including business and technical people. The writing is approachable and easy, and while the culture may be more Middle America than “Silicon Valley,” it’s a good characterization for the industry as a whole. As with The Goal, points appearing overly specific are not difficult to generalize into principles applicable in a different context.

(Bonus: tell me about “argle-bargle” and dinner is on me.)

Accelerate

What if someone claimed there were objectively measurable best practices shared by high performing team across the industry? I’d be skeptical, but my skepticism now seems unwarranted. As it turns out, there are statistical correlations between high performance technology teams and measureable activity.

Accelerate makes a bold claim: high performance software teams can be statistically correlated to a set of relatively simple-to-understand indexes. Well, this is triggering: everybody “knows” software is as much art as engineering. But the authors did the work: a statistical study of thousands of software development teams spread over several years. The results are both intriguing and actionable. Intriguing as many of the results found by the author are emerging as best-practice, and actionable for the same reason. (Best practices are almost by definition actionable.) While correlation is not causation, teams incorporating learning from Accelerate have some basis for focusing on even higher leverage activity.

Let’s take a look at the success factors and the key characteristics driving those factors.

4 success factors

Data-driven organizations need numbers. The best numbers are those which are simple to understand, and induce the correct outcome. Here are 4 measures the authors of Accelerate endorse:

  1. Lead Time — The time it takes to validate, design, implement and ship a new valuable thing;

  2. Deployment Frequency — The number of times per developer per day we ship to production;

  3. Change Failure Percentage — When you deploy to production so regularly, do you keep breaking it? Signs of change failure could be red deployments, bugs, alerts, etc.;

  4. Mean Time to Recovery / Resolution — If there is a failure during a change, how long does it take you on average to recover?

All of these measures are relatively simple to understand, possibly not quite so simple to implement. Measuring is an activity tax on production. Implementing automated measurement can drastically reduce the ongoing cost of this task, with the penalty of a much higher initial cost for the automation and process changes to support it, and the risk of spending to automate the wrong process.

24 key capabilities

Along with the four success factors, the authors list 24 key capabilities: 1. Use version control for all production artifacts; 2. Automate your deployment processes; 3. Implement continuous integration; 4. Use trunk-based development processes; 5. Implement test-automation; 6. Support test data management; 7. Integrate security into develoment; 8. Implement continuous delivery; 9. Use a loosely coupled architecture; 10. Empowered teams via architectur; 11. Gather and implement customer feedback; 12. Make the work visible through value streams; 13. Work in small batches; 14. Enable team experimentation; 15. Have a lightweight change approval process; 16. Monitor across application and infrastructure to inform business decisions; 17. Check system health proactively; 18. Improve processes and manage work with work-in-progress (WIP) limits; 19. Visualize work to monitor quality and communicate throughout the team; 20. Support a generative culture (Westrum); 21. Encourage and support learning; 22. Support and facilitate collaboration among teams; 23. Provide resources and tools that make work meaningful; 24. Support or embody transformational leadership.

That’s quite a list! I’m happy to report that Hinge Health makes the grade on many of the items on this list, and where we fall short, it’s great to have guidelines for improvement.

Recommendation

I wouldn’t say Accelerate is mandatory reading for anyone working with or on a technical team, but it comes pretty close. There really is a lot of information packed into a relatively easy read. I do give it my strongest recommendation: it’s worth rereading at least once, and it’s worth examining our own practices to determine how we compare to the practices described in Accelerate.

One caveat: the authors make a very strong case for necessity, but not sufficiency. A team must still be technically capable, and motivated, to succeed. Implementing all the recommendations in the book is not a guarantee of success; the book simply demonstrates that there is strong statistical correlation between these practices and successful teams. There is no silver bullet.