Will This Economy Finally Push the Toyota Way Into Software Development? | Hacker News Reader

Will This Economy Finally Push the Toyota Way Into Software Development?

techcrunchit.com

The "Toyota Way" is about process control in manufacturing. When will people learn that you don't manufacture code.

Lean is more of a operations philosophy than process control. There are elements that are perfectly applicable to software:

Kaizen: Floor-employees are encouraged, expected and empowered to make a Kaizen event when they observe that something can be done better.

Andon: Production-line employees are empowered to stop the line if they observe a quality problem.

A central pillar of lean is always to look at what you do, and figure our how to do it better, and to trace problems to the source and fix them there. It's easier to do in mass manufacturing, in no small part due to the fact that it's much easier to measure quality along a supply chain, than in anything custom built, including software.

It's basically about realizing that it's the people who do the actual work who are able to tell where, when and why your quality isn't good. At least every week there's a story on the daily WTF about a manager who "knows better" and overrules a developer with bad consequences.

The principles of lean could also be describes as "eliminating poor quality beforehand is far cheaper than scanning for poor quality afterwards" - ("Do not depend on (quality) inspection - build quality into the product and process" EF Deming). Seen this way, lean is even more necessary in software development than in manufacturing.

The problem is that, as you say, determining the exact source of poor quality in software development is more difficult than in manufacturing.

Software methodology is just a way for people who don't know what they are doing to sound like they know something, isn't it?

Part of the problem is that the discourse on methodology is mostly conducted by people who don't themselves do the work. Imagine a bunch of managers working out a "process" for, say, mathematicians. They'd be laughed out of the room.

I think good methodologies may eventually be worked out for software, but it will take generations and they won't look anything like what people (especially project managers) expect nowadays. Agile was actually a step in the right direction by comparison with what preceded it. But it's decadent now, having inevitably been overrun by consultants and vendors.

Not necessarily, but in practice, usually.

I wouldn't be surprised if it does. The conditions are right for it. Agile was gaining popularity even before the economy imploded.

Rails, TDD/BDD, and the general tenets of agile are things most in the industry have heard of.

The only issue is that any change is a risk and will require time, initially nullifying the time-to-market advantage they would get. Companies are not eager to take risk right now, nor are they thinking about something that will help them only once they adapt. They're in panic mode just trying to make it through the quarter.

That said, the benefits might be enough to entice at least some to give it a try.

I think the Toyota Way of thinking makes a lot of sense in software development.

It's definitely not just about process control in manufacturing. For example, there is a concept called "standard work" that describes how to do a particular job. I can imagine that being misused in software development. I tend to interpret it as suggesting that all work must be inspected, tested, and under version control (for example) rather than than suggesting that we are on some kind of virtual assembly line and all have to use the same text editor.

I would say agile is neither pure snake oil nor pure panacea. The fundamental idea of agile is to empower each programmer to start doing something without having to be held back by the complex dependencies of "big up front design".

Test Drive Development and typeless languages are at the heart of this. They let each programmer "start in the middle" so that the team is no longer working according to the situation where most of the team is hemmed in by the one guy working on the "critical path" and you no longer have to construct a whole, working system to see if your code works.

Now, the assumption of agile is that writing tests, refactoring and working at a constant, unhurried speed, a team is enough to allow the team to avoid "technical debt" - being hobbled by a design which the application has outgrown.

My experience, however, is that if Water Fall over-estimates the upfront design an application, agile underestimates it. It is quite possible to have serious design flaws in applications which have been developed via TDD. Architecture is a many-layered thing. For example, typeless languages are great for doing duck-type-based tests but they defining and reimplementing a documented interface hard. Typed languages are the opposite. Also, it is easy to write tests which assume a given architecture so that refactoring an architecture can thus suddenly becomes something everyone avoids - just the old situation where no one fixed structural bugs but instead worked around them.

Overall, there is no easy solution.

Reply on news.ycombinator.com