Industrial Engineering and Management building at the Technion in Haifa (Photo credit: Wikipedia)
I was talking with Lean/Agile Developer and overall smart guy Travis Dietz about requirements, and I brought up my old saw about requirements being inventory. It’s an analogy that comes from the factory, which is where a lot of the ideas that inform Lean software development and Kanban come from. Manufacturing was certainly Deming’s primary point of reference. Principles, techniques, and even artifacts (control charts, flow diagrams) in this way of thinking most likely have their origins (or at least their ancestors) in manufacturing and industrial engineering.
How appropriate is this, really?
I mean, the Agile community has fought and is fighting hard to correct a misunderstanding about software development that we largely owe to NASA: the misconception that most software development projects are not fundamentally different from any other kind of building project. You figure out what you want, an architect draws up all the plans, and the plans go to the workers to build out. Because the plans have already been made, you can scale productivity just by adding numbers. Also, past experiences should enable you to say how long a given development project will take if you can get a look at the plans.
In deterministic ways of building, this works all right. If I have to make car doors, someone has drawn up the plans for a car door, and it’s my job to crank them off the line. If my station averages 20 car doors a day, then when you ask me how long it’ll take to make a thousand car doors, I can give you a pretty good idea. This environment – deterministic construction – is largely the environment much Lean thinking was generated in and is almost Deming’s whole world.
Software development, however, is non-deterministic. Although you might have experiences that are similar at some level in the past, every problem is a new one. Every bit of software you write has never been done before (because otherwise, you could buy it or just re-use the code). Each feature is an act of problem solving and creativity, and we’ve all learned the hard way how quickly detailed plans become invalid. Once you get to the battlefield, you have to adapt. Software development is more like making a sculpture for a client than it is building them a car. Given that the nature of the work itself is rather different than manufacturing, how appropriate is it to use optimizations from manufacturing?
Let me begin by saying that to dismiss insights from manufacturing because it’s manufacturing is pretty dumb. Many advances in the field of software development did not come from software development, originally, and you should never close yourself off from wisdom that might come from a different field. If you’re going to rule out every field that is different from software development, then you’ve pretty much ruled out every field, including the ones that you like and use all the time in your software development. Math is a very deterministic field as well, but you’re going to have a hard time programming without it.
But the question remains, how far can we really take this? For instance, I have pointed out some things from martial arts that I believe have relevance to software development, but I don’t think practicing takedowns will help us write better software. I think the solution may be in the distinction between laws, principles, and techniques.
Laws are universal truths that everyone everywhere has to deal with. For example, people have to sleep. Therefore, no matter what field you’re in, you don’t want to schedule people for 24 hour shifts all month. People can only be in one place at one time, therefore, we do not assign people to five separate teams and expect them to be fully available to each one all the time. They’re laws built into the nature of the reality we all share, so dealing with these laws is automatically going to be something that spans all fields. Any insight that comes from some fundamental law of reality is pretty much guaranteed transferable somewhere else.
Principles are also general truths, typically derived from laws, but they are not always universal to all places and all times. “Avoid the Bubonic Plague” is a good principle, but generally speaking, it’s not really applicable to most people today. On the other hand, we might consider a principle like, “Employees should be empowered with the tools and authority they need to do their work efficiently.” Although you could probably find an edge case or two where this didn’t apply, it pretty much applies everywhere. Maybe someday when we live in a telepathic hive mind, concepts like “employee” and “authority” will no longer serve a purpose, but at least in our current context, it’s a pretty good principle and relevant to all kinds of work. When applied to many different fields, you see good results. I’d say that the vast majority of the concepts and recommendations of Lean, Kanban, and the various thought leaders in that area operate at this level. You have to understand how the principles apply in your context, but they are more or less truths that are bigger than a specific field.
Techniques are specific implementations/practices of something, usually derived from principles. These are only valid insofar as they operate in accord with their principles and are usually heavily conditioned by specific context. For instance, in most of the apostle Paul’s letters to churches, he tells them to greet each other with a holy kiss (Rom. 16:16, 2 Cor. 13:12, 1 Thes. 5:26). In the first century near east, a chaste kiss was a culturally standard form of warm greeting. It was a way to show that you were a community and had a level of affection for one another. In modern, American churches, you are likely to be maced when trying this out. In our time and culture, a kiss has romantic connotations, or at the very least suggests a particularly close affection like a relative or a very old and dear friend.
In modern America, the church members might shake hands, hug, smile, slap on the back – something that signifies warmth and community to us. The principles of community and affection span both times and cultures, but the specific implementations of those principles are very culturally conditioned, and if you went around to American churches trying to kiss everyone because “Paul told you to,” someone would rightly argue that you had confused the principle of Paul’s instruction with the cultural particulars, once they had slapped you.
It is in this area where, in software development, it is appropriate to go through these other industries at the practice level and decide if they’re really helpful in our context or not and, if so, do they need to be modified to better suit non-deterministic work? One good example is control charts. We (software developers) generally do our control charts based on probabilities rather than standard deviations, because we don’t have a consistent completion time we can use. The principle is the same – we are measuring our throughput so we can make informed projections, offer our customers service level agreements, and have conversations about things that look out of whack – but as for how that actually gets done, you can’t just lift the practice out of Toyota and drop it onto a software development team. You have to figure out if the practice will actually help you embody the principle, or whether it might need to look different or be scrapped altogether.
So, I will continue to borrow insights from manufacturing. That environment is much older than software development, and they have discovered principles about work, flow, quality, and how people perform their best that we’d be idiots not to consider just because it came from manufacturing. But when it comes to practices (and principles to some extent), we need to make sure we are thinking critically about the nature of non-deterministic work and the best way to embody those principles for us.