What does German soldiers during World War II have in common with the UNIX philosophy of “worse is better”?
Serval years ago I read a book by two Swedish authors Michael Tamelander and Niklas Zetterling about D-day. One of the things they study where the assumption that the Allied forces were superior to the Germans because the Allies won WWII. On closer examination this was not true, and neither was it true during World War I. In both wars the Axis powers were defeated due superior production capacity, manpower and resources of the allied powers. The book gives a surprising number of examples how of German forces would win battles despite surprisingly large odds against them.
To understand the superiority of the German forces on the battlefield, the authors look at how military training was done in Germany and how it was done in America and Britain. Allied soldiers were given problems to solve in the classroom. These were usually cases that involved tactics and strategy. The soldiers were given an hour to figure out the optimum solution to a problem on the battlefield. If after the hour had passed, they gave a sub optimal answer there were told to go back and think about the problem longer.
I think this is a good analogy to the MIT software engineering philosophy of doing “the right thing” as described Richard Gabriel. Getting the right solution at the battlefield is the highest priority.
When German soldiers were presented with the same kind of problems in the classroom they were given 7 minutes to solve the same problem. 7 minutes! That is orders of magnitude shorter time. How could their teachers expect them to solve these problems in such a short time?
Simple! They follow the UNIX philosophy of “worse is better”. Their solution didn’t have to be any good. It just had to be adequate. But there was one thing that is more important than anything. They came up with some solution in less than seven minutes. Spending more time than seven minutes was a failure.
The results of this difference in philosophy was catastrophic for Allied forces. By the time Allied forces had pondered the situation on the ground properly the realities had changed too much for their solution to be applicable. Germans soldiers, on the other hand were very dynamic and always adapting to the current situation.
I didn’t set out to write this post only about German soldiers and software engineering. These two examples were just outliers to get your attention. My main idea which is that these patterns emerge across a wide variety of disciplines. After reading Steve Yegge’s blog post about liberal and conservative developers. I was inspired by his idea to look for a grand arch that unites a lot of different themes.
I think my idea is even broader than what he described because it goes across so many different disciplines. I think there are better labels than liberal and conservative. I think this is better summed up in evolution versus intelligent design.
- evolution vs intelligent design
- market economy vs planned economy
- scrum vs waterfall method
- worse is better vs the right thing
- the bazaar vs the cathedral
- Toyota production system vs Ford production system
On each side of the table you have the same kind of ideas represented. The difference is just the difference in discipline and the language used to describe it.
Evolution vs Intelligent Design
I believe evolution presents these ideas in their purest form. It is counterintuitive that a process such as evolution is able to produce systems which are far more complex and advance than anything intelligent design has been able to do. By intelligent design I mean a intelligent human being or teams of humans creating a system or machine. Evolution is not intelligent. Evolution is not able to look ahead and see potential problems with a particular design. Essentially evolution churns out a lot of half-baked ideas, which are incremental modifications of existing solutions. Then it sees what sticks.
The reason why this works so well is because of the feedback system. People who don’t understand evolution very frequently overlooked this crucial part. If evolution was just random changes to DNA, one would never have been able to produce any organism.
The Cathedral and the Bazaar
This is a strong parallel to what’s Eric S Raymond describes as the cathedral and the bazaar. Like evolution he showed that by using a lot of mediocre software developers, coupled with frequent releases, a lot of users and lots of feedback, higher-quality software could be built than by a small team of exceptional developers. This team of intelligent and extremely capable developers represents intelligent design in the analogy.
When you designed the system, no matter how well you have thought about it you are likely to get some things wrong. If you spend a one time thinking and planning the solution there is a high chance that you veered off in the wrong direction. Evolution and the bazaar mode of development might not create very good solutions at each iteration. However each iteration is very short and feedback is given quickly so development can be adjusted before any problems compound themselves.
The human being has all kinds of design flaws which exist because evolution cannot look far ahead it’s always making small adjustments to what it has. That is why we have ended up with stupid designs like the cables going into the sensors of our eyes being connected at the front so that we get a blind spot. It is also why our spine is poorly suited for walking on two legs. However there’s little evolution can do about that because we started as four-legged creatures and were adapted from that.
We could compare this with software development by considering developing a computer game and we have the code for a four legged animal roaming around in our game world. Then we are given the task to add two legged humanoids to the game. There are two ways we could go about this. We could create the code for the two legged creature from scratch with some careful planning or just start hacking the code for the four legged creature until we get what we want. Hacking requires less sophistication, while creating the code from scratch requires developers with more skill.
We could actually see how something very much like this played out in real life with the Tanenbaum–Torvalds debate about Microkernels vs Monolithic Kernels. Or just look at HURD vs Linux. The ragtag group of hackers of varying quality managed to create a better product than elites designing the HURD microkernel.
Scrum vs Waterfall
At its most basic level this is really just about the length of one iteration in the development process. In Evolution or Scrum each iteration is really small, so in a given time frame one gets a lot of feedback to steer the development. Intelligent design or Waterfall method on the other hand, has very long iterations so that in the same time frame very little feedback is given to steer the development. It is hard to avoid going in the wrong direction. The result of this in the case of the Waterfall method one ends up making far too many features. 50% of the features delivered are never used. This increases the costs and time of development unnecessarily. With scrum on the other hand customer keeps getting new versions of the software all the time until they can say I’m satisfied with the results. This makes it very easy to avoid creating functionality that the users don’t need.
Ironically Scrum looks on paper much more wasteful than the Waterfall method. The reason is that since Scrum requires a fully working product at each iteration one has to tear up and rebuilds a lot of parts later.
Market economy vs planned economy
No person or government bureau plans how many toilet paper rolls, bread or cars should be produced in market economies. Figuring out how much should be produced of each item in a modern economy is an extremely complicated problem. And yet the problem is being solved by a surprisingly simple process, if:
- more people start demanding a product: increase the price
- fewer people start demanding it: decrease the price.
The first rule spurs companies to try to make more of the product because they can make more money. The second induce them to cut production. Like evolution a set of very simply rules are used to produce a very complex system.
Today we are conditioned to think that a market economy is superior to a planned economy. It is hard to appreciate how much sense planned economy makes intuitively. With a planned economy one can think about the economy and what should be produced for years ahead. For a while this actually works. Countries with planned economies were able to industrialize and grow their industrial production at amazing rates for a number of years. The reason a planned economy was able to channel much higher levels of resources into building factories and avoid duplication of effort. In a market economy lots of companies are spending resources to make almost the same product. At the face of it that seems very wasteful.
However planned economies ultimately fails to a large degree because of the information problem. You can read Joseph E. Stieglitz and Paul Krugman to learn more about this. As economies get more advanced, and there are more products to decide production levels for, the number of variables in your equations explode. Solving the equation or even getting the information needed to input into the equations become an impossible task. The result is the wrong level of production for all kinds of things. The Soviet Union was constantly plagued by overproduction of certain items and severe shortage of other random products.
This problem is perhaps not that different from the one faced by the software architects trying to gather all kinds of information about requirements of the software system that they will design. Like the Soviet planners, they will ultimately fail in getting all the information correct. Market economies and Scrum get stuff wrong all the time as well, but they get feedback quickly based on real usage to adjust quickly.
Toyota Production System vs Ford
There are a lot of differences between the Toyota and Ford production systems, but I will concentrate on those parts relevant to this discussion. The Ford approach to mass production is similar to a planned economy in that somebody at the top tries to figure out all the details of the operation. There are few local decisions as in a free market economy. Like intelligent design one makes a large upfront design where one optimizes the utilization of every machine.
This is done by e.g. placing a large buffer of parts at each machine in case there is a failure at one of the preceding machines at the assembly line. Thus the assembly line can keep going even when other machines fail. Like Waterfall we try to avoid failure by trying to anticipate what might go wrong.
The Toyota production system is more similar to Scrum, evolution and the market economy. Failure is celebrated because it gives valuable feedback which will help us improve. Batch sizes between machines are made small so that if any machine fails, big chunks of the assembly line is brought to a halt. That brings focus to problems. This is coupled with encouragement to regular workers to help make things work again. This is continuos improvement. So essentially you get a manufacturing system which is not set in stone but which improves through multiple iterations with lots of feedback.
This is analog to the Cathedral vs the Bazaar in the mediocre developers are used actively not just the elite programmers. Workers are helping making the assembly line work better. It is not just about the specialists and the engineers like with the Ford production line.
The Marshmallow Challenge
Peter Skillman came up with a design exercise called the Marshmallow Challenge. The goal was simple:
in eighteen minutes, teams of four must build the tallest freestanding structure out of 20 sticks of spaghetti, one yard of tape, one yard of string, and one marshmallow. The marshmallow has to be on top.
It is harder than it sounds. Among the interesting results from this was: the recent MBA graduates did worst at this exercise. Among the best performers were kindergarden graduates. The reason for this was that the kids used the principle of iterative development, while the MBA students focused on developing and executing the one true solution. So when they finally put the marshmallow on, the top the structure would collapse because they had not properly understood how to create the structure. The kids however started putting on the marshmallow very early on and learned from mistakes.
In other words the MBA students were using “intelligent design” or acting like Allied soldiers, while the kids were using an evolutionary strategy and acting more like the German soldiers.
User interface design
As a final comparison, I would like to share my experience with designing user interfaces for computer software. I find that developers often think they have a much better idea of how users think than they actually do. When some thought is being put into designing user interfaces it often involves people who are experts in the field arguing over what is best. These discussions can draw out for very long time, and are IMHO a total waste of time. After a lot of discussions back and forth they agree and build a system and then release it to the users. It turns out the users do not understand it. By that time it is too late. It was very expensive to build the system and too expensive to start changing it now.
I find it better to start testing with users using mockups. Instead of arguing over 2 solutions it would often be faster to just test each solution on a few users. By having lots of iterations and testing one gets the benefits of evolution over intelligent design in that the massive amounts of feedback allows one to quickly home in on the right approach.
Another important aspect of evolution, which I have not mentioned thus far, is the importance of large populations and a lot of variance. Natural selection is of no use if all individuals in the population are genetically equal. Nor is it useful if there are only a couple of individuals. If one only has one design to test it’s much harder to evolve it than if you have multiple designs. With multiple designs you can pick out the ones that work best and have them “mate” with each other.
This is not very different from how I have read that the design process at Apple works. They start with 10 prototypes for products and where one of the goals is that there should be a large variations in those prototypes. Then these prototypes are evolved and the bad ones are discarded through several iterations. At each iteration the remaining prototypes are developed further.
Unfortunately this way working does not seem to appeal to managers. Ironically they seem to think the same way as Soviets planners: that by throwing out the free market of ideas you avoid duplication of effort and can thus progress faster. They think it is wasteful that a lot of engineers are working on different solutions to the same problem. However, this is exactly why open source software has been so successful because there is a free market of ideas, which are constantly competing against each other. Ironically the open source world is much more like a market economy with respect to product development than commercial software development, despite not being driven forward by a profit motive.
Liberal vs Conservative developers
To piggyback on Steve Yegge’s ideas about conservative and liberal developers, I would say that Conservative developers are essentially developers with a much stronger belief in intelligent design. By having lots of advance tools, elaborate static type checkers and guidelines for software development one believes all the wasteful duplication of effort done by the developers following the evolutionary approach (Liberal developers) can be avoided. The Liberal developers follow a style of development that is more organic. Code is written, changed and thrown away more frequently. There are a lot more errors being made. Dynamic typing allows you to write the software faster and get feedback from the real world faster. Static typing on the other hand slows you down but makes it more likely that your program is correct each time it compiles and runs.
Evolution, market economy, German soldiers, “worse is better” - all derive their advantage by using small iterations, each guided feedback from the “real world” of the previous iteration. Intelligent design, water fall method, “the right way” etc on the other hand, have long iterations, and thus little feedback.
I don’t really aim with this to say that intelligent design is always worse or inferior. This is more to caution against the thought that there is a always a shortcut that avoids duplicated effort. The thought that if we just think hard about it we can just build the product right away without creating prototypes that we have to throw away later.