Discussion

discussion@lists.fsfe.org

1 participants
3272 discussions

DevOps inspiration from Toyota Production System and Lean considered harmful
by Carsten Agger 18 May '22

18 May '22

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-prod… 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_critic… <https://research-api.cbs.dk/ws/portalfiles/portal/58521158/IRIS_2017_critic…>) 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=rep1&t… <https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.323&rep=rep1&t…>) 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=203907F7926472DB3… <https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=203907F7926472DB3…>) 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-pub… <https://www.jacobinmag.com/2012/09/lean-production-whats-really-hurting-pub…>) 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/2114… <https://www.industryweek.com/operations/continuous-improvement/article/2114…>, 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>

2 2

Call for Free Software at Bits&Bäume22
by Erik Albers 11 May '22

11 May '22

Hello everyone, the Bits&Bäume Conference is a conference on the subject of digital sustainability and it took place in 2018 for the first and only time so far. This year however there will be the next edition of Bits&Bäume and this time the FSFE is part of its organising committe. We are only one of many organisations, but our goal is of course to have many interesting topics around Free Software in connection with digital sustainability. You can find the call for participation here: https://bits-und-baeume.org/konferenz/en Registration deadline: June 7th The text of the call for participation is quite long, but you will see that this is true because there are actually many different ways to participate. Lectures and workshops can be submitted, but also art and science, conceptual gatherings or other creative forms of activity. "Start-Ups" also have the opportunity to present themselves to a jury in a "Pitch and Thrive". As you can see, the format is really very open to contributions and I would be very happy if we could see a lot of Free Software topics being covered on the different stages : ) And while I can't help you to get your submission through, I am happy to help if you have any questions or want feedback on whether your format might be of general interest or not. Feel free to ask me directly about it. And also feel free to distribute this mail further on any other list from that you think there are people who will be actually interested in it. Questions and ideas of general interest could be for example * Lectures on different dimensions of the sustainability of Free Software (technical, economical, social ...) * Your favorite Free Software that contributes to sustainability * A piece of hardware that you were able to give a new life to with the help of Free Software or extended usage time * Increased resource efficiency of your computer through free software * Organizational sustainability through the use of free software and Opener Standards * Sustainable knowledge management and and and Best regards, Erik -- No one shall ever be forced to use non-free software Erik Albers - Programme Manager Digital Sustainability Free Software Foundation Europe (FSFE)

1 0

Is Matrix a good choice?
by Dr. Trigon 18 Mar '22

18 Mar '22

Has anybody read https://www.hackea.org/notas/matrix.html ? What is the position of fsfe regarding these issues?

9 16

FSFE and the war in Europe
by Vitaly Repin 18 Mar '22

18 Mar '22

Hello, I have to raise your attention to the fact that since February, 23 we have a war in Europe. Latest press releases from FSFE are: - 2022-03-16 KDE's Okular becomes the world's first eco-certified computer program- 2022-03-15 Germany: 100 days of coalition agreement - hardly one day for Free Software- 2022-03-10 "I Love Free Software Day": Free Software games and a SharePic generator I understand that these news might be important. But it looks really strange to not say a word from FSFE (Free Software Foundation _Europe_) about the war in Europe. Yes, FSFE is not a polictical organisation. But what happens now is beyond any politics. This is a full-scale war which happens now and here, in Europe. I feel that FSFE MUST issue an official statement about the war and actions of Russia. I do not know how free software activists and organizations can contribute to the peace in a more meaningful way than by issuing statements. But I believe that the statement shall be made as a bare minimum and it shall be crystal clear. Silence is not an option. -- WBR & WBW, Vitaly

7 9

The French administration is looking for projects for their summer of code (in French)
by Cryptie 15 Feb '22

15 Feb '22

Hi all, For those it may interest, the French administration is looking for groups, French companies and public administration who develops Free Software and are looking for contributors. All information about their summer of code is available here (in French) : https://communs.numerique.gouv.fr/bluehats/bluehats-semester-of-code/ Deadline the 6th of march at 23:59 paris time. Best, -- Cryptie Free Software, Free Society one daily commute at a time Free Software Foundation Europe mailto: cryptie_at_fsfe.org xmpp: cryptie(a)jabber.fsfe.org diaspora: cryptie** on diasp.eu

2 1

Re: [FSFLA] LibreJam - FSF* should host a Libre Game development tournament!
by Ismael Luceno 14 Feb '22

14 Feb '22

On 18/Jan/2022 18:03, Dennis Payne wrote: > You did ask an actual indie game developer. I chose "We" in my > statement because I was including myself in the group of game > developers. I recently made Anagramarama available for sale on itch.io > to gain funds for free software game development. I also have a > merchandise shop where I've started trying to make money for free > software game development. > > If you want commercial closed source game developers, I've done that > two. I worked on the game Devil's Whiskey. I enjoyed the experience > and made money from it but don't particular enjoy closed source > development so I haven't done it since. <...> I meant, to make a large representative sample. I wish everyone was of your opinion, but I've been hearing otherwise from the majority of people I talked with; geography, environment, economy, and other factors might play a role in which groups are louder and/or larger. It would be important to understand who they are, their positions, and what might prevent their games from being free software.

3 2

upcoming I Love Free Software Day 2022
by Bonnie Mehring 10 Feb '22

10 Feb '22

Dear all, Just a heads up: The "I Love Free Software Day" 22 will be taking place next Monday, 14th of Feb! I am very excited for this years "I Love Free Software Day". As we have plenty of new features. First of all we will have a Free Software gaming event in the evening from 18:00 o'clock till 20:00 o'clock. The agenda looks like this: 18:00 – 18:05 Welcome and Introduction FSFE 18:05 – 18:25 Flare: Free/Libre Action Roleplaying Engine with Justin Jacobs 18:25 – 18:45 Vassal: Free Software Game Engine with Joel Uckelman 18:45 – 19:05 Godot Wild Jams with Kati Baker 19:05 – 19:20 Veloren: Free Software Game Presentation of the game by Forest Anderson 19:20 – 20:00 Gaming time Veloren (https://veloren.net/) 20:00 Closing remarks There will also be a stream for the talks on: https://stream.fsfe.org Our second new feature for this year's "I Love Free Software Day" is our sharepic generator: https://sharepic.fsfe.org If you would like to participate in the day with some creative messages this is a perfect opportunity to do so :) I am very much looking forward to your participation in the "I Love Free Software Day". For more information about the day and all the new features have a look at: https://ilovefs.org Best regards, Bonnie -- Bonnie Mehring - Junior project manager - Free Software Foundation Europe Schönhauser Allee 6/7, 10119 Berlin, Germany | t +49-30-27595290 Registered at Amtsgericht Hamburg, VR 17030 |(fsfe.org/support)

1 0

Re: [FSFLA] LibreJam - FSF* should host a Libre Game development tournament!
by Ismael Luceno 14 Jan '22

14 Jan '22

On 07/Jan/2022 18:23, Dennis Payne wrote: <...> > Most people developing games would love to make a living as game > developers. However I disagree that most people developing games are > motivated by it. We are usually motivated by a game we want to make. We > might think it could make money but usually it is the desire for the > game first. > > People join National Novel Writing Month for the same reason. They have > an idea for a novel and want to write it. Some will pursue publishing > it. Some will self publish perhaps even knowing it won't be a giant > seller. Some will just give it away. Yes, it could be the case, but I wouldn't count on it. But instead of guessing, we could just ask actual indie game developers.

1 0

Re: [FSFLA] LibreJam - FSF* should host a Libre Game development tournament!
by Jean Louis 09 Jan '22

09 Jan '22

* Dennis Payne <dulsi(a)identicalsoftware.com> [2022-01-08 17:23]: > On Fri, 2022-01-07 at 10:53 +0100, Ismael Luceno wrote: > > People who value free software would publish their games as free > > software... Why don't we have so many games then? > > We do have a lot of games. Obviously not as many as commercial games. > They tend to steer towards procedural or acade games rather than > complex story games. High quality graphics are less common but not > unseen. > > https://trilarion.github.io/opensourcegames/statistics/index.html > Lists 519 linux games at the moment. Some may not be completely free > but a good chunk of them probably are. It has a backlog of games to add > as well. It is unclear what "open source" means, there are many "custom licenses" and "other licenses". > Most people developing games would love to make a living as game > developers. However I disagree that most people developing games are > motivated by it. We are usually motivated by a game we want to make. We > might think it could make money but usually it is the desire for the > game first. > > People join National Novel Writing Month for the same reason. They have > an idea for a novel and want to write it. Some will pursue publishing > it. Some will self publish perhaps even knowing it won't be a giant > seller. Some will just give it away. Great, keep it going. Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/

1 0

Re: LibreJam - FSF* should host a Libre Game development tournament!
by Richard Stallman 07 Jan '22

07 Jan '22

[[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] For practical success, it is desirable to make the game easy to install. To respect users' freedom, it is important to avoid dependence on any nonfree software. To let the community make sure the program is safe and not malware, we need to encourage users to package the program for distros. (See https://gnu.org/philosophy/free-software-even-more-important.html.) It is important to achieve all three goals. The second is often ignored, but then the free software idea is forgotten. The third is one we often forget. Can you find a good way to achieve all three? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)

6 14

← Newer
1
...
8
9
10
11
12
13
14
...
328
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Discussion