People Working in DevOps Should Read the Toyota Way

Toyota, as a manufacturing organization, makes some of the best cars in the world.<p>Toyota, as a software writing organization, fucks it up so bad that people die. There was a single procedure in their ETCS system that was 1300 lines of C with no unit test plan and global variables out the fuckin wazoo. Whole ETCS had 10,000 globals.<p><a href="https:&#x2F;&#x2F;users.ece.cmu.edu&#x2F;~koopman&#x2F;pubs&#x2F;koopman14_toyota_ua_slides.pdf" rel="nofollow">https:&#x2F;&#x2F;users.ece.cmu.edu&#x2F;~koopman&#x2F;pubs&#x2F;koopman14_toyota_ua_...</a>

I thought the Toyota Way&#x2F;DevOps analogs had been done to death to a degree that they became practically a cliche. (Though admittedly I was attending a lot of DevOps events at one point.)<p>In general, this is a worthwhile read though. The lessons <i>can</i> be overapplied in part because a lot of lean manufacturing approaches do have a lot of focus on inventory which mostly doesn&#x27;t apply in a software development context. However, as the author notes, there are also philosophical aspects to the the Toyota Way which are relevant.

I stopped believing in TPS when I saw how companies did terrible things with workspace&#x2F;office organization and supply management under 5S methodology.<p>Basically, workers got uncomfortable, de-personalized workspace; no spare parts and materials and less inventory.<p>Maybe it is aestherically pleasing for the management, maybe its easier to audit, but no worker like to work in such system and many of the dogmas actively hurt productivity.

I would also say that anyone espousing The Phoenix Project should also read The Goal, on which it is based.

I thought the Google SRE book was more actionable with a better set of principles to follow.

I never found likers writing to be compelling. I’m sure the foundational ideas are great but I found other books about Kaizen were more interesting