I met with a Fujitsu executive last week, and we naturally got onto the topic of software development methodology. I presented my case that it is critical that programmers know the actual customer because 90% of all decisions that effect usability are made by the lowest programmer. He countered with a story from his own experience of how a race car mechanic and driver have to work as a team.
He explained that he used to drive race-cars before joining Fujitsu. The driver and the mechanic are both critical to winning a race. The driver experiences the car in one way, while the mechanic experiences the car in a completely different way. The driver can not adjust the engine, and the mechanic can not drive the car. The driver and the mechanic have to develop a way to communicate about the performance of the car. The driver will describe the experience, the mechanic will translate this to what it might mean for the machinery of the car. The mechanic might make an adjustment, and see how the driver reports the change. Over time they will develop a special language to talk about how the car is performing, and how performance might be improved. They iterate in order to perfect this language.
What I like about this story it that it emphasizes teamwork along with clear specialization of duties. Having the driver adjust the engine is pointless, and having the mechanic drive the car is equally pointless. There is no short cut: they have to collaborate, and they have to find that common language in order to do it.
He employed this as an analogy for software development: there is the role of the designer architect and the role of the programmer. The designer architect understands the customer and has to learn how to communicate to the programmer who tweaks the product. Each specialize in their domain, and work together to make the final product.
Sounds good, but for one thing: complexity. Much of what we do in software involves ways of coping with overwhelming complexity. How complex is car-racing? Consider the degrees of freedom that a car driver has: accelerator, brake, gear, steering, speed, acceleration, turning rate, etc. Possibly 10 dimensions to play with. While cars seem complicated, they have between 5000 and 15000 parts. Within the engine, there are again only a few controls, possibly 10 different ways to control the engine performance. More and more the engine is controlled by software, but make no mistake: in the end there are only so many ways the engine can be tweaked.
The complexity of a typical large software program is a thousand to a million times more complex. While a car may have 5000 parts, many of those parts are very simple, like a bolt or a nut, and duplicated many times identically. However, a million line program, each part of that program is unique, and infinitely variable. A single method (subroutine) may be called from hundreds of places, but that method is not duplicated in any way analogous to how small parts are manufactured for a car. The physicality of a car engine forces the designers to limit the size and number of parts but since software has no physicality, the collection of parts of the program can grow without limit and without significant (direct) cost.
The thing about highly complex systems is that approaches that work for small examples simply don’t scale to the large scale. Usability is about many very very small things. It is easier to write a program, than it is to write a document to describe the program. If a designer architect was to communicate about every button, every gesture, on every screen, there would not be enough time in a century to cover a modestly complex program. It is certainly true that the high level goals of the program can be communicated in the same way as the driver/mechanic do. But “usability” requires an understanding of the customer, how the customer is going to use it, and what the customer values are, by the actual programmer who writes the code. There are thousands of detailed decisions that a programmer makes; if made correctly the customer loves the final product, but made incorrectly the customer hates the solution, even if it meets every specified requirement. To address this, agile software approaches do two things: seep the development team in the culture of the customer, and do many rapid iterations so that the customer can see it as it develops, and provide early feedback to correct the course. You set up feedback loops that are fractal in nature, and work at all levels to improve the final product, including usability.
I like the story of the driver and the mechanic, but I fear it mainly confuses people by trying to take “hardware thinking” into the software realm. In complexity circles, it is well known that “wicked problems” are not solved by scaling up an approach to a small example. While it is certainly true that there are many roles that professionals need to play, and they do need to specialize, and learn to communicate, however this does not mean that you can eliminate the need for programmers to understand the customer. Particularly if you want a product that customers love to use.
P.S. Reviewing a great new book by John Gøtze et. al. called Beyond Alignment which has many articles about approaches to Enterprise Architecture that try to address the extreme complexity of organizations. Look forward to a summary, soon.
Keith, really good post. Having raced motorcycles myself (and getting back into car racing in 2014) I can relate to it well. There are multiple layers of performance, reliability, driveability, durability, maintainability and adjustability that make a racing machine, racing team and a driver a winning combination. The job of the engineer is to make the driver look good on the racetrack. Enable him to do more than he could be himself — the hallmark of great solutions! Believe it or not – a race car must be much easier to drive than a road car as you are taking it to extremes and can’t start to fight the machine when the going gets tough. After having managed that kind of interaction — THEN the real world comes in — the drivers and engineers mood the days before a race, the track to be raced, the weather, the competitors out on the track and finally Murphy’s Law. What can go wrong will go wrong.
This is truly complexity. Now does anyone believe that working a 9 to 5 job serving customers is any different? Racing is just a form of taking manageability to an extreme and test the limits continuously. Actually, being in business and wanting to compete does exactly the same thing. There are no safe bets if you want to be excellent. There are only process management delusions and faked statistics. This is why I wrote about ‘The Value of Failure’ some time back. Without failing you don’t even know where the limits are and what to improve! In this years presentation series I had a slide with a quote from Mario Andretti: ‘If you think things are under control, you simply aren’t going fast enough!’
There is absolutely no difference between hardware, software or brainware. To make it all work together (aka collaborate) you are absolutely right that a well-defined communication needs to take place. That needs a collaboration framework which will not be BPM, Social or ECM, and well-defined language that allows all participants to communicate with as little problems as possible. Yes, any example of dealing with complexity is a good example for doing business.
Pingback: The Fall of Server Side Web Frameworks | How to JBoss