What Happens to Bad Software?

sadThere are a lot of things that happen to bad software. Back in the early 80’s, Atari decided to bury their bad software in the New Mexico desert. Literally, bury it.

It’s not 1983, but bad software still gets buried. It gets buried in a different sense. It gets bought by another vendor and “updated”, it’s “transformed” from a server-side application to a “cloud-based platform”, and lest we forget the “let’s customize the heck out of it until it’s unrecognizable and works better” (or worse in many cases) approach.

If you’ve been in technology for any length of time, you’ve probably worked with bad software. What makes it so bad? The bugs? The worthless GUI? The endless hours of futile user acceptance testing?  To me, it seems that there’s a gradual tipping point for bad software where the project goes from “Wow, let’s buy it” to “Well, let’s see how the requirements and design phases play out” to “did they even unit test this?” to “the end users hate user acceptance testing because the bugs are so bad”.

How can bad software be fixed? Or, can it be fixed at all?  Honestly, bad software is a real challenge.  You’ve got users who are being told by their managers that they have to use it, senior managers who are trying to ensure that they’re not scalped by their CEO / CFO for purchasing bad software, and a technical team managing so many workarounds related to the bad software that there are workarounds to the workaround.

If your project is using the Waterfall software development life cycle approach, the decision to pull or somehow salvage bad software has to be made early.  Don’t attempt optimism in the case of bad software.  If it’s broken and you know it, go back to the vendor and work with them to fix it before you roll it out to your end user population.  Keep in mind that this will probably throw your project into the red and you won’t be the most popular person until you get the project back on track, but it’s worth it. Talk to your stakeholders and explain the situation, because end users shouldn’t be held responsible for unit testing a bad software product.  However, if your project is using an Agile approach, you’re usually in a better place, as the 30 day sprints are more flexible and allow iterative changes to be made to the product.

As project managers, we’re responsible for the entire project, including (unfortunately) bad software. So, come up with a game plan to work with your vendors, stakeholders and project team to ensure that you aren’t rolling out bad software. Your end users will thank you!


2 thoughts on “What Happens to Bad Software?

  1. Hi Darcy,

    I disagree about the Waterfall vs Agile part of this post, where you’re saying that software managed through Agile can be salvaged even at later stages, while software managed through Watefall can only be salvaged early in the development phase.

    I think the best thing to do with bad software is to dump it – I have been working in this business for a very long time now, and I now that at least 50% of the software is flushed own the toilet, regardless of the methodology used.

    • Hi PM Hut – Thanks for your comment. You make a great point, however, in an Agile environment I’ve found that it’s easier to right a broken ship due to the iterative nature of the methodology. I do agree that there comes a point even in Agile where the decision has to be made to dump the software and you’re correct that 50% (maybe more!) of software is flushed down the toilet. Thanks for your comment and my apologies for not posting it earlier, I’ve had some issues with the comments on WordPress.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s