Author:
Han Schaminee is general manager Navigation and Automation at Wärtsilä Voyage.
Reading time: 4 minutes
Would Edsger Dijkstra believe that we oversimplify projects when using Gantt charts, wonders Han Schaminee.
In the seventies of the previous century, one of the mandatory exams for people studying mathematics in Eindhoven was called “The art of programming.” Lectures were given by the legendary professor Edsger Dijkstra, famous – among other things – for his work on the first multitasking operating system and the shortest path algorithm, still the basis of many navigation algorithms. As students, we tried to replicate his approach to programming, but it was only after many years of working as a software engineer that I started to understand what it was all about – and to appreciate it.
It wasn’t about a set of tricks to derive efficient and correct programs; it was about managing an often-underestimated complexity by simplifying but not over-simplifying. The machines we try to control can be in one of an enormous number of states and our programs should be such that the behavior is as expected in all these states, even in cases where inputs are different than may be anticipated.
This is really what engineering is all about. Like a mechanical engineer making his design robust enough to withstand conditions that may never exist, a software engineer makes his software work for any state the hardware can be in. This requires a particular way of thinking. Verifying if your program works for a small defined set of events won’t do; it needs to be mathematically established that it always works.
Moreover, the software should be robust, as in adaptable at minimal costs against future changes (ie Agile). That’s why modern architectural methods don’t start from a top-down defined requirement specification but from a set of components that can be used in a much wider application area than suggested by the requirement specification. The software industry has learned that traditional requirements management doesn’t work when facing uncertainty about what to make and how to make it. As said before, software engineering isn’t about coding but about architecting a future-proof customer solution.
In March 1968, Dijkstra published an article entitled “Go To statement considered harmful.” I was re-reading it during a recent business trip, and got excited again. Dijkstra explains why it’s important not to focus on the actions of the program itself but to reflect on the states the executing machine can be in and how the program functions irrespective of these states. He also explains why a goto statement makes it so much more difficult to reason about all the states of the machine; the statement adds complexity rather than managing it. Programming isn’t about defining some actions that have to be executed; it’s about managing a system that can be in one of many states. Programming is about managing that complexity. Still, I often encounter software that’s designed as a series of actions as well as people who are surprised that it’s not working except for a few happy flows.
The article made me reflect again on the Agile way of working as a way to organize yourself for the unforeseen. And on the many people who prefer to define a project as just a sequence of activities. Agile is a better approach – it’s about managing that uncertainty for projects and their output to become more predictable.
People highly value predictability. Of course, predictability has a lot of value when you have to synchronize weakly connected processes. When the shop changes its inventory in September to be ready for Black Friday, you better have your product available. But in too many cases, we unnecessarily demand predictability, leading to buffers, lower productivity and even lower predictability. I once met a manager who thought the way to overcome his software problems was to make all engineers sign a document on the delivery date! It didn’t work. You can’t delegate uncertainty to a level where developers have no influence.
Using Gantt charts fits well within this predictive attitude. A Gantt chart can be very useful to visualize dependencies and can stimulate thinking about the critical path, but I often see it used for micro-planning. I hardly see Gantt charts visualizing a buffer at the end and progress reporting in terms of budget usage. They typically don’t allow for specification variation, which is one of the most effective ways of becoming predictable. So, as the goto statement is a sign of a wrong programming attitude, the Gantt chart used as a plan to stick to is a sign of a wrong leadership attitude. And therefore, after Edsger Dijkstra, I consider the Gantt chart as harmful.
