Projects or death marches?
To those of you who don’t know him, Ed Yourdon is one of the fathers of software engineering. His book about “Modern Structured Design” from 1989 has been very important and has contributed to create a tendency (I have studied it at university and I’m not so old!!)
Curiously, fourteen years (and many projects) after that he wrote a new book called “Death March“.
Death marches started during World War II and were a (very sad) way to try to get rid of the prisoners of war without killing them directly (sometimes). They consisted in making the prisoners of war march without water, food and shelter through battle fields where they were exposed to extreme weather conditions, hostile fire or land mines.
With this term, Yourdon tries to describe the reality of many project teams where people frequently feel “unarmed against crossed fire (opposed interests) or power struggles”, where they are supposed to make an “additional effort” to counteract the problems derived from lack of planning, budget shortage, or lack of quality for processes.
It doesn’t seem logical that the organizations and their managers that are so experienced still intend to embark on those “death marches” that lead them, with high probability, to lose money, and image before their customers and their own employees. In spite of that, as shown by many statistics, death marches are each day becoming the norm more that the exception.
Yourdon exposes a series of motives that move organizations into death marches, and also the reason why many employees still embark on those projects. Some of the reasons will be familiar to more than one: impossible promises made by marketing? power struggles that have nothing to do with the goals of the project? Marine corps mentality (real programmers don’t need to sleep!!)? Shrinking projects more than reasonably to win a tender? The list could continue…
Even though Yourdon is one of the most influential people in software engineering, he is also coherent with his own suggestion to apply methodologies with common sense and he proposes not to seek the “silver bullet” that will save us miraculously, but instead to stick to those simple practices that have proven successful before. Apart from that, he also suggests to try to negotiate for the best team members and to concentrate all the efforts to solve at least the most critical needs that can still give the project some meaning.
Despite all that, Yourdon also admits that in certain situations the best way out could be to actually get out of the way… what is also known as “to vote with your feet” 😉
Curiously the big consultancy firms, who live on doing projects, usually have many of these problems: An optimistic marine corps mentality, blind faith on new technologies, project managers without enough experience that make “innocent” plans, “agressive” salespersons that are paid by order entry and not by profitability, etc. In these scenarios, it is not strange to see turnover rates of around 30% anually… meanwhile “from the other side” the “prisoners of war” are asked for “committment” and “motivation”.
In spite of all of this, I do believe that there is still some hope. It is clear that software engineering still has a long way to go, but companies in general don’t have good feelings for projects that are too big and they usually try to define phases tha allow them to detect earlier if they are on a death march (although sometimes they still don’t want to see it) On the other hand, agile methodologies are starting to show more clear results and at least some of their good practices start to be implemented.
As always, I’m open to other’s opinions.