
People Working in DevOps Should Read the Toyota Way - zwischenzug
https://zwischenzugs.com/2019/11/06/why-everyone-working-in-devops-should-read-the-toyota-way/
======
curuinor
Toyota, as a manufacturing organization, makes some of the best cars in the
world.

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.

[https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_...](https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_slides.pdf)

~~~
munmaek
Jesus, reading that was completely horrific. It's total software gore and
terrible practices, in critical car systems..

Accountability and proper practices just go out the window when dealing with
invisible code, I guess. It's 2019 and we're still dealing with things like
storing passwords in plaintext or overusing global variables. Sometimes I
wonder what's the point of even being a programmer?

~~~
0_gravitas
personally it helps with imposter syndrome, its like thinking youre a terrible
writer and then reading some godawful bestseller like 50shades of gray and
realizing "hey, i guess i cant really be that bad"

~~~
artsyca
Yes, once you realize the level of imposterism and mimcry going on in software
you realize 'hey I can do this too' it's empowering in a twisted way -- I
suggest doing it from a position of first principles and reinvention rather
than feeding the frenzy

------
ghaff
I thought the Toyota Way/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.)

In general, this is a worthwhile read though. The lessons _can_ be overapplied
in part because a lot of lean manufacturing approaches do have a lot of focus
on inventory which mostly doesn'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.

~~~
navaati
> inventory which mostly doesn't apply in a software development context

I heard a guy (a Factorio youtuber who was manager in his dayjob, haha) say
that it did apply indeed, if you see inventory as "what has been produced but
not shipped, stuff for which the value has not been delivered for", in
software context that being unreleased features. It made a lot of sense, and
ties all nicely into the notions of short iterations and release early,
release often. That was interesting.

~~~
ghaff
I don't disagree. Hence my "mostly" qualifier. One can certainly imagine
processes that lead to a lot of unintegrated components, code that should be
"done" but won't pass tests, etc.

It's still rather different from manufacturing inventory management but it's
not totally unrelated either.

------
altmind
I stopped believing in TPS when I saw how companies did terrible things with
workspace/office organization and supply management under 5S methodology.

Basically, workers got uncomfortable, de-personalized workspace; no spare
parts and materials and less inventory.

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.

~~~
linksnapzz
...curiously, this has not had the effect of workers voting to unionize at any
of Toyota's plants in the US, where they have that option.

Of course, as the managers of Suzuki put it when they were building out the
CAMI site in Ontario...you don't adopt another company's production system
exactly, any more than you would wear a suit tailored to someone else.

~~~
bdcravens
Doesn't stop programmers from arguing for a process because Google does it.

~~~
jacquesm
Especially when they are completely ignoring the fact that what works for
Google usually works for Google because they have achieved a certain scale,
not that Google achieved that scale by adopting these methods.

~~~
pytester
To be honest there are a lot of processes that don't work for google either
but with their treasure chest of money and profits from an easily defended
monopoly flowing in, it's really hard to argue that.

I can still remember all of the people who defended the brainteaser questions
microsoft and google used to toss at interviewees. If I was right that they
were bullshit why wasn't _I_ worth a billion dollars?

~~~
artsyca
I must be in the twilight zone -- could this thread be the watershed moment
where sanity prevails in software?

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

~~~
jammygit
I really enjoyed the Phoenix project but I have to admit the practices they
followed in the last 1/4 of the book were barely described and simply worked
almost like magic.

~~~
orev
I think they ran out of time or ideas by that point, and intended to follow-up
with another book: The DevOps Handbook, which took them a long time to finally
get around to writing.

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

~~~
jammygit
How much do they overlap conceptually?

------
jammygit
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

