Avoiding Development Disasters is the tile of an article I came across today and talks about how and why software projects fail. Here's what I got out of the article.

FBI Virtual Case File

The article opens up talking about the monumental failure that is/was the VCF and touches 6 factors which lead to the projects failure.

• Lack of an Enterprise Architecture - Unfortunately the article doesn't go into what they did have, have not.
• Poor management of developers, including a lack of management or micro-management
• Unqualified persons were placed in critical roles
• Constantly changing requirements
• Scope Creep
• Throwing more developers at the project in a last ditch effort to meet deadlines.

I am personally experiencing 3 of the listed items on a current development project, although it's far from a $100 million dollar system, I bet there are some striking similarities. I would imagine that every project at every company experiences 1 or more of the things in that list to some extent or another.

What is Success?

The VCF was eventually scrapped, but the author claims, that had it gone to production, it would have been deemed a success, even with all it's flaws. The author goes on to say that this is the general practice in the software industry (at least enterprise applications). As much as I like Microsoft, I think Vista is a shining example of this (although perhaps it is deemed less of a success inside of Microsoft).

I have to agree, and would be willing to say it's common in software projects in general, from small to large. How many times is a game released, and the day of, a patch is released? Even Epic Games, creators of the Unreal platform, and who coined the phrase "When it's done", still manage to release a product with known issues.

I'm not trying to criticize any one company or developer, other then myself, as I have created some less then magnificent code over my short life as a developer. I think part of the problem is that there are no points for creating good code. At the end of the day, "Well it works doesn't it?" pays the bills.

Why is it so hard to write code, almost 30-40 years since the first programs were written? We have better tools, faster computers, and years of other people's failures to learn from, and here we are, still producing less then our potential.

The Code to Ruin

The diagram "The Code to Ruin" presented in the article is so true, it's scary. You pretty much know what's going to happen before you start the project, but you still can't avoid it. That's depressing at best.

Maintainability

The article spends the last half, talking about the maintainability of code. Without code that is maintainable, while you launch may be a success, you next point release is probably going to be a failure. The article states that enterprise software should have a 15 year life span, that's longer then I have been coding.

I think ideas such as software as a service might help us reach that goal, and have more maintainable code overall. I'm not taking about providing software as a service, I mean, that the internal make up of your application is constructed from (loosely coupled) services. Breaking stuff down into more manageable pieces seems to be the way to go. We already do it with proper OOD design, we should also be applying it to the system in general. Of course there is a trade off, the most notable to me being one of performance, but that's what these faster computers are for ;)

All in all, it was a good article, and made me really think about software projects, both past and current that I am working on. I have to imagine that there are people out there that would be the perfect compliment to a talented programmer such as myself (well at least I think I'm talented). Or, does it mean, that I need to spend less time with technology and programming, and learn more skills like project management, documentation, business analysis, etc.? To specialize, or generalize, that is the question?