Culture of fear

Yes, it’s a project from Hell, but who’s to blame?

Yes, it’s a project from Hell, but who’s to blame?

This tale of a project from hell (from Twitter, above, direct link to the original article) got me thinking this past week.

On the surface there’s the pure technical story, the gory details of a trainwreck of a project that makes for fascinating reading, but reading further into it and what really stands out to me is the efforts at deception that were employed to cover up the ongoing failures.

A literal trainwreck to accompany the figurative trainwreck.

This is the portion of the article that really got me:

At some point, an official delivery was scheduled, totally independent from any kind of planning set within the team. When the day came, the customer was actually sent a blank CD with installation instructions because nobody had been able to build the software in weeks. The customer found out they had been delivered a blank CD, officially complained, and was given an old version to replace the previous delivery. They found out because the displayed date in the “About” box was the same as last year.

The deceptive behaviour that this quote highlights is symptomatic of a business culture driven by fear and manifests in an unwillingness to tackle uncomfortable situations with honesty.

Nobody sets out to write bad code, or to create bad software, but the slow degeneration of a codebase over the lifespan of a project is almost inexorable. This project has been going on for 12 years, which is going to be tough on anyone. That’s why you need a good development team working to maintain the code as well as extend it. That’s not what this project has:

Management decides to reduce costs and fires all experienced people, hires people with little or no software experience.

Average turn-over for the newcomers: 3 months, the legal time to leave your job in France.

This project has a bad codebase, that much is obvious — just reading through a few of the key statistics demonstrates the scale of the challenge:

50,000+ classes

Database software from a company gone bankrupt

Several layers on top of each other to handle the Graphical User Interface, none of which actually maintained by the authors.

Startup time is about 15 minutes

Mean time between crashes: 30 seconds to 30 minutes

The root of the problem is not the code though, it’s the business culture. Yes, the code is awful and the project is awful, but it’s the business that fostered this, the business that existed at the project’s inception, that allowed it to degenerate into the state it was 12 years on, and the business that attempted to cover up their mistakes with deception, which is to blame.

Speculation

Fear is the likely driving emotion behind these decisions. Securing a government contract is alluring for a business, not least because of its scale and financial security, but often it can form too large a part of the businesses’ incoming work, and then having a client with too much leverage over you can colour your interactions with fear and skew your ability to have those awkward, honest communications.

Being fearful of the important communications at work is a bad thing. I work for Deeson and we try to avoid that by being open and honest. We’ve open-sourced our Handbook and Delivery Manager Holly Davis produces the bi-weekly Make Good Newsletter, which is all about project delivery. We don’t want our own a ‘Project from Hell’ anymore than you do.