People Working in DevOps Should Read the Toyota Way
zwischenzugs.com
zwischenzugs.com
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_...
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?
Hey let's run our shop like a factory
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.
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.
It's still rather different from manufacturing inventory management but it's not totally unrelated either.
I like The Phoenix Project because it specifically addresses this by showing how they apply in a warehouse and in a cube farm.
I don’t really think you need to dogmatically apply all 5 ways to every environment every time, but it’s helpful to remember them and try to see which might apply any time you run up against a problem.
Things like removing a roadblock, even if it slows you down even more to cross-train someone else in dealing with whatever task is causing the bottleneck is, in the end, in everyone’s interest.
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.
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.
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?
And yeah, while Honda is considered an engineering-led organization, Soichiro Honda was the son of a blacksmith who may very well have not finished highschool. He was an obsessively skilled mechanic and designer, and had famously little regard for college-educated engineers who would make simple mistakes an experienced mechanic would avoid.
That race win in the '60s prompted Lee Iaccoca (then at Ford) to want to source Honda engines for the new Escort small car to be sold in Europe. Henry Ford II quashed that idea, saying "no car with my family's name on it will have a Jap engine!". Too bad.
5S can be a huge trap for businesses that don't realize what the intent is. This is another philosophical item, which doesn't necessarily involve putting labeled bins on everyone's desks and having precisely calibrated seating positions and standardized desk chair models. In our case, we apply the principles of 5S to how we manage our issues and labels in GitHub (which we consider to be a virtual factory floor) not to our physical workspaces.