The Toyota Way at Codeweavers

I've been around long enough to see software development methodologies come and go. I worked for GE for a decade, and they tried to force Six Sigma on everyone. Devs put through training. Lean. KanBan. Single piece flow.

The thing that businesses don't want to hear is that software development is a skill game. You win by having better players. You cannot put blind process around every facet of it. I know you'd like to, so that you can then pay very little for unskilled labor. But the fact remains that you cannot, even today.

Wysiwig html editors and drag and drop UI builders for rapid application development were trending for a while in the 90's. Then everyone realized that giving these tools to monkeys resulted in a big pile of poo. So the trend reversed back to hand coding UI layouts using markup, separating business logic from display concerns, etc

I guess what I am trying to say is that if there is any hope in putting a lot of process rigor around software development, it will be enabled by tooling. Until then, skill and experience matter. And they aren't cheap.

Put another way, if the Cleveland Browns stole the New England Patriots playbook, they would still suck.

I have to laugh at this. I know this is in reference to their manufacturing process, but I have worked with Toyota's IT department and they don't follow anything like this. They are a typical stodgy, waterfall, design by committee, ivory tower architect kind of IT department. We pushed agile on them, but they still insisted on signing off on 100-page BRDs before work started. Maybe I just had a bad experience, but I recall constantly wondering why we had to work so hard to sell agile on the organization that practically invented it.

> Whilst on the surface it is all about manufacturing cars if you dig a little deeper, particularly into Taiichi Ohno’s work, you soon start to see how these rules can be applied to all kinds of manufacturing and we saw many parallels in what we were reading about the Toyota Production System and the way we delivered our software.

I found this really interesting. I completely agree that the principles behind the Toyota Production System can be applied to many other disciplines than just car manufacturing. I wonder if Toyota itself actually applies its own principles when it comes to software development. When their software got audited as part of the unintended acceleration case [1] it was described as spaghetti code and having generally poor engineering practices.

I'd be interested to know why this seeming discrepancy exists between Toyota's quality in hardware vs software.

[1] http://www.safetyresearch.net/blog/articles/toyota-unintende...

The cornerstone of Lean Manufacturing is removing waste.

One of the largest historical sources was inspection and repair: you built something and then inspected it and fixed any problems. The inspectors and repair people didn't really talk to the production people much.

In Lean Manufacturing, the main purpose of inspection is to drive process improvements back into production. (This is the simplistic explanation, but I'm only using this as an analogy)

Thinking about data management - there's a lot of dirty data out there, and a lot of data munging to fix it up. Lean Data Management would drive process improvements into data acquisition.

Of course on the other hand, it's extremely cheap to fix data, on a per-unit of data basis. It's rule management that's expensive.

I have read the books on the Toyota Production System and it does not apply to software, except in a very loose general sense. Manufacturing is not at all similar to software because with manufacturing you are making the same physical thing again and again, while with software you are only making a thing once, and it is intangible.

There are benefits for examining the flow of deliverables and information, and trying to eliminate waste, but much of the TPS is geared around the manufacture of physical objects and it is a stretch to apply it elsewhere.

I think the core flaw here is thinking of software development as "manufacturing". It isn't at all. It's a design process.

This Toyota methodology is about taking things that have already been designed and then incrementally improving them or figuring out better ways to put them together.

Building software is more akin to the process of taking a blank sheet of paper, a knowledge of what kinds of parts already exist, then designing a new car to fit a new market segment.

I worked at a software company that went through a "lean transformation" where management effectively idolized Toyota's production philosophy and wanted it used in each and every department.

While it helped our customer service department quite a bit as-is. The Toyota Way is definitely not something you can directly copy/paste and use in software development. Building a Camry 5000 times is not the same as shipping 5000 different software projects, so a lot of the analogies and examples you find in text don't always apply. I always found it amusing that you never see or hear examples used from the R&D and engineering of the actual automobiles -- just once all that hard stuff has been figured out and the manufacturing starts, all the principles are magically, easily applied.

To be honest, a lot of it is just "common sense" or things that just naturally transpire if you have a good team (especially if Agile dev and ideas like continuous delivery are used anyway.)

With the negatives aside, the problem-solving culture part of it is something that can really change things for the better and is worth researching. If nothing else, I found just being able to have a framework for solving problems as they come up is huge -- surely regardless of what a company does. For instance, integrating a standard to collectively write out the "Five Why's" and clearly define the problem statement when a team is gathered to discuss solutions to a problem can save so much time. How many times have you been dragged into a meeting, go through a huge discussion, design a solution, only to realize later that it wasn't really solving what needed to be solved?

Outside the culture aspects, it mostly just felt forced, frustrating devs, and really made things feel almost like a cargo cult waiting for the goodies to drop from the sky.

Is this the Toyota that put together cars that killed multiple people? The ones that were shown in court to be ASTOUNDINGLY incompetent? The ones whose developers didn't even have access to a bug tracker? The ones who followed only 4 of 90+ automotive industry standard 'required' or 'suggested' practices? The ones who didn't use even basic static analysis tools?

I'll pass, thanks. I know it's all fine for Toyota because the courts ruled essentially "Its computers and nobody knows how they work! We can't convict them of criminal negligence!" and it saves them billions by not hiring experienced people or giving engineers the tools they need or training them or anything like that... but I actually have a conscience and don't mind if I make a little bit less money if it means there won't be the dead bodies that are my responsibility like Toyotas got.

If anyone would like to read more about the real lean techniques in software (not just kanban), I recommend Lean Software Strategies book.

https://www.amazon.com/Lean-Software-Strategies-Techniques-D...

The West has a tendency to cherry pick techniques from holistic approaches (for example quick path to mindfulness vs meditation and Buddhism). I suppose it's a cultural difference. In my opinion, it is really worth it to try to understand Lean as a whole instead of looking at kanban only.

If you want to try Lean/Toyota Way in your sofware business, in addition to reading the suggested texts at the end, check out Mary & Tom Poppendieck's books. They offer a lot in terms of already translating lean production concepts into lean software design/development concepts. They also offer exercises that can help you move towards being lean. Because being lean isn't a state, it's a goal and a process.

I've been in software since the 80's. I've watched all the fads and cults rise and fall .. From General Electric to Kanban and back again.

Honestly, over the decades, there are very specific patterns in all the ism's, and its the recognition of these patterns which each new generation of ignoramus decides to make their own and turn into the Hot New Cool Shit.

So I feel its really necessary to point out that while, with the Toyota Method, there is very definitely a refinement of techniques that have been well-worn, and proven, indeed in many markets around the world - there are still parts of the human psyche of productivity which remain unexplored.

One of those aspects, I feel, is the obfuscation and neglect which occurs with every wave of computer culture.

We kind of don't really work on the reasons for obfuscation - because obviously this is not productive. Productivity means, getting the shit done, in a way that increases value - for the individual producers as well as the owners of the means of production.

Toyota works. The proof is in the fact that it is one of the biggest and best brands in the world.

But what doesn't work is the occlusion of methodology that occurs, which makes the revelation here in the 21st Century of time-worn, centuries-old methodologies, relevant.

We get this way because we decide to occlude, forget, neglect, and ultimately .. reject .. the ways of the masters. How many of us read this article, gave it a cursory glance, and decided to close the tab, for whatever reason: "its too preachy", "its a culture thing", etc. And what number of us actually decided to incorporate the Ohnno way into our thinking, for the simple fact that HN gave us the clue?

Really, what I would like people to understand is that there is a desultory, occluding factor, to these different 'ways'. The moment the marketing people take over a working technology, they decide to brand-differentiate, and this means forgetting the roots of it all. "Nobody thinks of the sugar; all we see is the cola" can only happen if we actually act on the basis of ignorance.

The point being, the Toyota way seems - like so many other ways - to have the principle purpose of fighting ignorance. Ignorance of oneself, ignorance of others, of the customer/user, of the managers, and so on. Ultimately, the Zen approach is, remember that you will always be forgetting, and express your current reality in such a way to defeat that. No successful brand is ever forgotten; no successful methodology can happen in a vacuum. Yet: it requires such a vacuum before you can find your own handle on it, and ultimately apply it with success.

"Applying it with failure", on the other hand, is a sure-fire to re-invent something else, 'brand new', again and again.

Don't you feel there is something inherently intrinsic to Toyota Method? Well, there should be a list of these feelings, by now, for those of us who have been paying attention for decades ...