I wrote a rant against the idolization of Lean and Toyota among certain DevOps people. Originally it was the synopsis for a more thorough article which I don't have the time to write, so instead I present only the conclusions. Maybe of interest to people here involved in programming (or union work and working conditions, for that matter) since DevOps is everywhere these days and has its good sides too.
https://blogs.fsfe.org/agger/2022/05/12/devops-inspiration-from-toyota-produ...
DevOps inspiration from Toyota Production System and Lean considered harmful
*Note: This text was originally the synopsis for a much longer article which I intended to write as the followup to a lightning talk https://hackmd.io/@DgwTpN18RPqYa3pK_-o2eA/B1gGTzZ1c#/ about the subject I did at my workplace. Acknowledging that I probably won’t get time to write the long version, I think this synopsis can stand pretty well on its own as a statement of intent.*
DevOps and DevOps-related practices has become a huge thing in the software industry. Elements of this, such as Continuous Integration and Continuous Deployment and the focus on monitoring production systems and metrics has resulted in large improvements in the handling of large-scale deployments. Especially, the act of deployment to production, in traditional systems often an error-prone process riddled with cataclysmic pitfalls and requiring huge amounts of overtime, is reduced to the trivial pushing of a button which can easily be done in normal office hours.
While the success of DevOps largely rests on technological improvements (containerization, orchestration systems, ease of scaling with cloud technologies) as well as process improvements originating in the Agile methodologies as they have developed since 2001 (with concepts such as pair programming, Test Driven Development and a general focus on automatization), much of the literature on DevOps contain a strong “ideological”, to the point of evangelization, promotion of the underlying philosophies of Lean production and management systems. One very conspicuous feature of this ideology is the canonization of Japanese management methods in general and the Toyota Production System (TPS) in particular as an epitome of thoughtful and benign innovation, empowering workers by incorporating their suggestions, achieving world-class production quality while simultaneously showing the maximum respect for each and every one of the humans involved.
This method (the TPS) was, the story goes, introduced in Western manufacturing and later in management, where its basic principles – improvement circles (kaizen), value stream mapping, Kanban, etc. has streamlined the basic business processes, improved productivity and reduced costs. Now, the narrative continues, DevOps will apply these same Lean lessons in the software industry, and we can expect similar vast improvements of productivity.
It is problematic, however, to try to “learn from Toyota” and from Lean Manufacturing without examining in detail how these work in practice, not least how they affect the people actually working in those systems. The authors behind some of the more popular DevOps introductions – The DevOps Handbook and the novels “The Phoenix Project” and “The Unicorn Project” – do not seem to have actually studied the implications of working under the TPS for Toyota’s Japanese employees in great detail, if at all, and seem to have all of their knowledge of the system from American management literature such as James Womack et al’s “The Machine that Changed the World”, basing their own Lean philosophies entirely on Toyota’s own public relations-oriented descriptions of their system.
This is problematic, since it overlooks the distinction between Toyota’s corporate representation of the intention of their production system – and the actual reality felt by automobile workers on the shop floors. Darius Mehri, who worked at Toyota as a computer simulation engineer for three years, has pointed out that the Western management movements inspired by Toyota have failed to understand a very fundamental distinction in Japanese culture and communication: The distinction between /tatemae/ (that which you are supposed to feel or do) and /honne/ (that which you really feel and do). Mehri posits that all Western proponents of The Toyota Way fail to realize that what they are describing is really the /tatemae/, what management will tell you and what workers will tell you in a formal context when their words might come back and harm them – while the /honne/ is much grittier, much darker and much more cynical.
In effect, proponents of Lean manufacturing and management styles have imported a kind of double-speak in a Japanese variant, but similar to the all too well-known difference between corporate communcations and what workers will confide in private. By doing so, they have inherited the fundamental lie that the priorities of the TPS are respect for each individual employee, partnership between management and workers, and involvement of each and every employee in the continuous improvement of the workplace; while its true priorities are a maximization of profit through the imposition of frenetic work speeds and very long working hours, discarding workers afflicted by the inevitable accidents and work-related diseases – and an “innovation” mainly driven by imitation of other manufacturers.
The truth about the very Toyota Production System that inspired the Lean movement is, leaving the /tatemae/ aside and looking at the /honne/, that these factories are driven unusually ruthlessly, with little or no regard for the human costs for the workers on the shop floor. Meetings, security briefings and announcements are routinely made after or before actual working hours, when workers are on their own time. Assembly lines are run at extreme speed in order to increase productivity, resulting in serious accidents, chronic work-related diseases as well as production defects. Even so, production targets are set unrealistically high, and the shop crews are not allowed to go home before they are met, often resulting in several hours of daily overtime. The “improvement circles” do exist and workers are indeed asked to contribute, but the end goal is always to increase production and increase line speed, never to create more humane working conditions on the shop floor. Such improvements are (if at all) introduced more grudgingly, e.g. as a consequence of labor shortages and worker dropout.
Lean, by lauding the TPS and uncritically buying its /tatemae/, is introducing a similar /honne/ of its own: It is, in reality, /not/ revolutionizing productivity, and for all its fair words does /not/ promote the respect of each worker as an individual. On the contrary, the relentless focus on constant “improvements” and constant demand that each employee rationalizes their work as much as possible has caused it to become known as “management by stress”. It may indeed focus on metrics and may indeed choose metrics to demonstrate its own success – while achieving results that range from average/no change to absolutely dismal.
Proponents of DevOps should /stop/ presenting Toyota as any kind of ideal way of working – literally, a nightmarish grind with workers forced to do ten- or eleven hour shifts, ignoring accidents, running beside old and worn-out machinery in outrageously dangerous conditions is /not/ where we want to go. And the “ideal Toyota” with its “improvement kata” and “mutual respect” never existed except as the /tatemae/ to the cynical /honne/ of shop-floor reality. By importing the /tatemae/ as though it were Truth itself, the Lean movement has imported its double-speak – Lean or “management by stress” transitions can be very unpleasant indeed for employees, and while everything is shrouded in talk of partnership and mutual respect, the underlying motivation will often be money-saving through layoffs – the /honne/ to the Lean management bullshit’s /tatemae/.
That is to say: Perpetuating the lie about Toyota as a humane, innovative and respectful workplace is /positively harmful/ to the employees and processes afflicted by the proposed improvements, as the double-speak involved will inevitably rub off. The Toyota /tatemae/ was not, after all, designed to be practised literally. Accepting it at face value will only set us up for further double-speak in our own practice.
While the software industry can and should continue to evolve based on the philosophy enshrined in the Agile Manifesto https://agilemanifesto.org/ and the improved work processes introduced by DevOps, we should eschew the mendacious narrative of Happy Toyota and reject the Lean philosophies that it founded.
REFERENCES
Heather Barney and Sheila Nataraj Kirby: /Toyota Production System/Lean Manufacturing/ in “Organizational Improvement and Accountability: Lessons for Education from Other Sectors”, RAND Corporation 2004 (online: https://www.jstor.org/stable/10.7249/mg136wfhf.9 https://www.jstor.org/stable/10.7249/mg136wfhf.9).
Ian Hampson: /Lean Production and the Toyota Production System – Or, the Case of the Forgotten Production Concepts/, Economic and Industrial Democracy & 1999 (SAGE, London, Thousand Oaks and New Delhi), Vol. 20: 369-391 (online: https://library.fes.de/libalt/journals/swetsfulltext/6224179.pdf https://library.fes.de/libalt/journals/swetsfulltext/6224179.pdf).
Jeffry S. Babb, Jacob Nørbjerg, David J. Yates, Leslie J. Waguespack: /The Empire Strikes Back: The End of Agile as we Know it?/, paper given at The 40th Information Systems Research Seminar in Scandinavia: IRIS 2017 – Halden, Norway, August 6-9, 2017 (online: https://research-api.cbs.dk/ws/portalfiles/portal/58521158/IRIS_2017_critica... https://research-api.cbs.dk/ws/portalfiles/portal/58521158/IRIS_2017_critical_170501_submission.pdf)
Darius Mehri: /The Darker Side of Lean: An Insider’s Perspective on the Realities of the Toyota Production System/, Academy of Management Perspectives *20*, 2, 2006 (online: https://www.jstor.org/stable/4166230 https://www.jstor.org/stable/4166230)
Stuart D. Green: /The Dark Side of Lean Construction: Exploitation and Ideology/, proceedings IGLC-7, 1999, 21-32 (online: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.323&rep=rep... https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.323&rep=rep1&type=pdf)
Satoshi Kamata: /Japan in the Passing Lane: : An Insider’s Account of Life in a Japanese Auto Factory/, Pantheon Books, New York (1982)
Gregory A. Howell and Glenn Ballard: /Bringing Light to the Dark Side of Lean Construction: A Response to Stuart Green/, proceedings IGLC-7, 1999, 33-38 (online: https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=203907F7926472DB31... https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=203907F7926472DB31BBE75D290A826B?doi=10.1.1.418.4301&rep=rep1&type=pdf)
Will Johnson: /Lean Production – inside the real war on public education/, Jacobin Magazine, December 2012 (online: https://www.jacobinmag.com/2012/09/lean-production-whats-really-hurting-publ... https://www.jacobinmag.com/2012/09/lean-production-whats-really-hurting-public-education/)
Mike Parker: /Management-By-Stress/, Catalyst Magazine /1/, 2, 2017 (online: https://catalyst-journal.com/2017/11/management-by-stress-parker https://catalyst-journal.com/2017/11/management-by-stress-parker)
Gene Kim, Jez Humble, Patrick Debois and John Willis: /The DevOps Handbook/, IT Revolution Press, Portland (OR) 2016.
Gene Kim, Kevin Behr and George Spafford: /The Phoenix Project/, IT Revolution Press, Portland (OR) 2015.
Gene Kim: /The Unicorn Project/, IT Revolution Press, Portland (OR) 2019.
Phil Ledbetter: /Why Do So Many Lean Efforts Fail?/, https://www.industryweek.com/operations/continuous-improvement/article/21144... https://www.industryweek.com/operations/continuous-improvement/article/21144299/why-do-so-many-lean-efforts-fail, 20/9-2020.
Enid Mumford: “Sociotechnical Design: An Unfulfilled Promise or a Future Opportunity”, https://link.springer.com/content/pdf/10.1007/978-0-387-35505-4_3.pdf https://link.springer.com/content/pdf/10.1007/978-0-387-35505-4_3.pdf
On Sunday, 15 May 2022 19:22:43 CEST Carsten Agger wrote:
I wrote a rant against the idolization of Lean and Toyota among certain DevOps people. Originally it was the synopsis for a more thorough article which I don't have the time to write, so instead I present only the conclusions. Maybe of interest to people here involved in programming (or union work and working conditions, for that matter) since DevOps is everywhere these days and has its good sides too.
https://blogs.fsfe.org/agger/2022/05/12/devops-inspiration-from-toyota-produ...
I saw this and, being partial to a good rant myself, considered commenting on it. I think the adoption of Lean techniques and related methodologies and practices, already controversial in organisational settings where people might find their jobs incorporating elements of those techniques on the insistence of management, has been undertaken rather uncritically (or cynically) not just in DevOps but in software development and maintenance generally.
Naturally, there will always be good reasons for evaluating the way people work and deliver results in other industries, particularly when those industries appear to be better at managing projects and producing products within time and budget constraints. And when people introduce elements of practices from outside the software industry, skepticism is usually countered with an insistence that lessons need to be learned (which I generally agree with) combined with suggestions that skeptics don't want to change their ways (which I obviously do not agree with).
Often, people have to accept such changes as a complete package, having their reservations downplayed or mischaracterised, and this is how you can easily end up with situations where good and useful techniques become packaged up with less good and potentially harmful practices, perhaps even escorting some other kind of agenda through the door. If you find yourself identifying and resisting that broader agenda, it is entirely possible that you might risk being categorised as "unprofessional" precisely because of a deliberate conflation of practices, incentives and organisational politics.
It is interesting to consider how things have changed over the years, what improvements have taken place, and what kinds of problems or problematic trends have emerged. I think back to my consulting days a couple of decades ago and it is fair to say that some things have moved on. Some of those things are technology and tooling improvements, whereas others are social or behavioural.
To take an example of a clear improvement in a technological form, people were using tools like CVS to manage their source code back in my consulting era, but few people were using things like branches, partly because tools like CVS offered a rather incoherent experience with a lot of potential for mistakes and confusion. When distributed version control systems became more prominent, the industry gradually adopted them and started to leverage the benefits they brought with them, thus changing development habits, mostly for the better.
Meanwhile, to consider practices that were deficient back in that era, I remember the project I worked on having to deliver documentation on how the software deliverables were to be installed, with a Word document being painstakingly crafted, handed over to a bunch of other consultants (from the same company), who then copy-pasted or retyped commands from the document, handing it all back for revision if something didn't work. At that time, it was obvious (but not to the rather backward project management) that the proper way of delivering the system was through automation, with documentation supporting that automation.
One can argue that the whole consolidation of development and operations into DevOps builds on the realisation that developers cannot merely do their thing and then hand it over to other people to roll out. Developers should not be tempted into thinking that they operate in an ideal environment, although they are usually disabused of such thoughts at university. However, one can also argue that the two domains may require different skills and abilities and that combining them dilutes an individual's necessary focus on two potentially different activities, and it also excludes other necessary activities.
One prevalent trend that remains a source of conflict within the Free Software realm (and elsewhere) is that of emphasising container-based deployment (Docker, Flatpak, Snap, and so on) and seeking to bypass traditional software distributions. We have all surely heard it said that distributions provide packages that are "too old" whose maintainers "get in the way" and that other ways are needed of getting the absolutely latest stuff. This narrative plays into the whole DevOps culture: the developer has to get their stuff out there, has been given or has taken on this task, and nothing should get in the way.
The problem with this empowerment of the "ops-conscious" developer is that it eliminates any kind of role that seeks to preserve a coherent deployment environment: the job a distribution package maintainer might do where someone might consider whether the software is deployed correctly, has the appropriate level of privileges, interacts with other software harmoniously, and so on. Somehow, DevOps must absorb these concerns, but instead they are increasingly neglected or denigrated, as noted above.
Consequently, the industry has evolved in the absurd direction of giving every application its own container or virtual environment despite running in a multiuser system that already has plenty of facilities for isolating applications and restricting privileges (although I would accept that those facilities might need some adaptation). In effect, it almost seems that developers now expect to get their own virtual mainframe for their so very important applications.
Even though there are benefits in having the ability to "spin up" virtual machines on demand, and having been exposed to things like OpenStack I don't deny that it can be fairly convenient, tools need to be developed and provided to manage all these machines if everything gets its own "private mainframe". Coordination or orchestration of these new-style units of computing also becomes necessary. I remember tedious meetings with the customer in a consultancy era project about which network ports were required by our software, presumably to be scribbled into a Word document. There are certainly arguments to be made for capturing all of this and integrating it using technology, but I have reservations about the stack of complexity being built.
Perversely, as all this complexity spills out, presumably to be managed by big companies with big datacentres, the measures to manage complexity are arguably being neglected at the developer level. As developers clamour for the latest latest, and to be able to roll it out at any time, all those university-taught software engineering practices like compartmentalisation, defining stable interfaces, and so on, have been abandoned in favour of continual system-wide changes and pervasive refactoring, mitigated by the magic merge in people's version control systems.
And where traditional software distributions have been rejected, developers tend to seek similar levels of convenience elsewhere. It appears that this is sometimes just a matter of pulling container images from Docker Hub or some equivalent, or it is a matter of pulling down packages from the likes of CondaForge, or even pulling down images containing packages from these non- traditional distributions. Frequently, these alternative sources leverage traditional distributions, but don't expect anyone advocating these alternatives to acknowledge their hypocrisy. And as people rush to package for maximum instant convenience, don't expect distribution-level quality control, either.
People could potentially mitigate development chaos by laying down stable components in their systems that do not need instant access to the latest updates from upstream development repositories, and this would then lessen the need for highly customised software stacks and deployment environments. But this would need a mindset change, not only among developers but also in the industry at large. After all, developers are not acting as they do purely because they want to: it is because the nature of the work has changed, and it is because something has to give when they need to get the work done.
This is where I belatedly return to the social aspects of introducing potentially inappropriate methodologies to the software industry. We have all seen waves of "rationalisation" wash into the industry over the years. When developer salaries were seen as too generous, outsourcing and offshoring pushed many of the supposedly interchangeable developer jobs to low-cost venues with the idea that the grunt work could be done on the cheap, albeit managed by high-salary consultants. Such trends neglected well-established observations that good communication is essential in software projects, and so quality and productivity suffered as a result.
What we arguably see now is a form of redefinition of the roles within the industry, consolidating them into a kind of singular role where the occupant is required to be "responsive" to whatever the demands of the job are, where such demands are deliberately diverse so as to save the costs and the bother of having specialists, and also to permit those occupants to be interchangeable. Not that the motivation for this latter concern is necessarily benevolent, either: while it is good for knowledge to be shared in an organisation, the motivation for having redundancy in an organisation is often the potential for making people redundant entirely (that is, letting them go).
When I pursued a computer science education, I had hoped to find meaningful and rewarding work in the industry, but the kind of "responsive" roles we see now are effectively shallowing out the nature of the work. People are increasingly expected to deliver direct-to-user improvements on a continuous basis and to immediately respond to problems on an "everything has top priority" basis. Wiping out distinctions between "development" and "production" or "pre-release" and "release" might have ridden the industry of tortuous "beta" phases and software that has not been given enough user exposure, but it risks eliminating stability for both users and those who have written the software.
A significant risk for the industry is the effect this has on endeavours that require a sustained development focus without constantly being obliged to tweak something or other for the supposed benefit of users. Some will respond to such concerns by claiming that there are plenty of good-enough solutions out there already and that people should take the consumerist approach of picking and choosing, mixing and matching, and just give up on any significant new (or humanely pursued) development effort. All this does, however, is see people pile more and more stuff on top of the existing stuff - a heap of dubious complexity - to try and do what they need to get done.
Another risk for the industry is a kind of concentration of power and influence in organisations that are able to dedicate people to making solutions that the rest of the industry, in its constantly hassled state, end up having to adopt. Where does that leave individuals, developers or normal end-users, having to effectively "take it or leave it" with regard to the software they may obtain, whether it is Free Software or not?
I get the feeling that an upper echelon of the industry would quite like to see the rest of the industry as nothing more than virtual warehouse workers, scurrying around with their genius-designed products, bundling them up on a just-in-time basis and grateful for the privilege of doing so. This vision has not been delivered on previous occasions, but the one thing you can guarantee is that the last time somebody tried, it wasn't the final time.
Paul
On Sunday, 15 May 2022 19:22:43 CEST Carsten Agger wrote:
I wrote a rant against the idolization of Lean and Toyota among certain DevOps people.
Sorry to follow up again, but at least this message is shorter! Previously, I've noted the cult of "innovation" in academia, but I haven't provided bite- sized pieces of evidence, so here we go:
"How do you build Life Science startups that are viable and scalable? This Lean Innovation Course will bring you up to speed thinking more entrepreneurial, how to steer and grow your start up, and how life science- based ideas can become commercialized."
https://www.digitallifenorway.org/events/lean-innovation-course%202022.html
Being "entrepreneurial" and commercialising ideas is basically background music in academia these days. When they say commercialising ideas, they mean patenting, of course, although you're not supposed to be able to patent mere ideas, but anyway.
Paul