The Codist

Software project disasters come in all shapes and sizes; in my 25 years in this industry I have seen almost everything. Here are a few disasters described and illuminated for your reading and gagging pleasure. I doubt anyone involved in the software industry hasn’t experienced several of these types. There are 6 in the pipeline, I may think up more.

• The Train Wreck
• The Death March
• The Sisyphus Project
• The Ten-Foot-Pole
• The Kitchen Sink
• The Painless Upgrade

Any similarities to the The DailyWTF are purely a figment of this industry.

In the next few articles I will write up the disaster types with a description, an example, and some thoughts on how to avoid the disaster.

The Train Wreck

Description A train wreck is a project where everyone assumes things are going well, progress is being made, and it appears that everything will turn out well. In reality, the train is barreling down the tracks at good speed until it hits the bridge that is out and then crashes spectacularly into the valley. No one is actually driving the train and all anyone sees is out the side windows, so the illusion of progress is great.

Example The best example of this common project type I will call "Country Doctor". A team of entrepreneurs had the brilliant idea of selling a new, modern medical clinic management package for a specific specialty. Aided by a new government mandate (HIPAA) requiring everyone update their software, and having a killer feature no one else had (that would save clinics lots of money), it was a sure fire hit at trade shows and sales calls. People not only paid in advanced but many offered to invest in the startup as well. Now all that was needed was the software.

One of the founders knew a project manger in another state that they had worked with, and this person happened to know an architect who could design the application, so a development office was opened in the most expensive real estate area in the country. The architect came up with a object model, but had no interest in UI design or managing development so the project manager hired a large group of contractors to work on the UI and database pieces along with the business logic. Since the application was way too secret to show to anyone, the application was sliced vertically (from database to UI) and each contractor was only allowed to see the source of their slice. Any contractor who tried to look at source they were not working on was fired. With no one to look over the entire design massive duplication and outright conflicts were everywhere. But the reports coming from the development office to the business team was always positive and a few bits of the app were visible so everyone was excited about progress.

Of course the business team knew nothing of development, the sales team sold the sizzle without having to try, and each developer got closer and closer to delivery. Then came the start of beta, when a few lucky clinics would start use this wondrous package. First they hired a few industry experts to make sure no detail was missed. Bad idea, the first time anyone who actually knew medical accounting saw the package they realized it was completely unusable. Every screen worked differently, features appeared in no particular order, important features (like paying bills) were not even working; it was an unusable mess. Now the entrepreneurs had a big problem, as the HIPAA deadline was approaching and all these clinics had given money by the handful and disasters would happen if the software wasn't ready. So they hired the company I worked for to "fix" the code.

Our first inkling that something was wrong was getting the source. Apparently no one had ever compiled the entire application from source, due to the "security"; they simply compiled a slice and added it to the existing binary. After a month of work we managed to get something running but the horror of the sliced up application was apparent and no amount of work would every make it usable, other than a complete rewrite. But our company was desperate for money so we kept working anyway. Eventually we tried to get paid for all our work but they ran out of money, closed the doors, and ran for the hills. I bet the lawsuits are still chasing after them.

Solution Train wrecks survive due to a lack of open communication among all the participants, a fear of honest status reporting, and most principally, a lack of visible progress. My example had even more problems that I can easily document but the inability of the company founders to have an independent eye on the progress of the application (no domain experts until the end) made it far too easy for the train to move to the crash.

Modern iterative schemes break up a project into smaller repeatable units, where the application is always functional at the end of the iteration, and can readily be examined. It's hard to have a train wreck where the train stops every mile while everyone looks around. There is no excuse for anyone to be "surprised" at the delivery date. It is also imperative that non-technical management have knowledgeable, trustworthy people able to explain what is happening in language they can understand, and that they listen.