Build Better Software.

ACME Widgets had a problem. The system they had been using to manage the inventory of their widgets was not designed for the type of volume they’d grown to produce. Their employees were frustrated and it became obvious that they needed a solution to help them keep everything under control.

After a thorough search for local software companies, ACME contacts Hamster Software to see what they can do about solving their problems with the widget inventory. They liked what they saw on Hamster’s website, and having no experience with software development, assumed by the look of the website alone that Hamster would be right for the job. They weren’t wrong, but they weren’t completely right either.

So ACME and Hamster Software start to talk about how to solve the problems with the widgets. Internally, Hamster’s team knew they hadn’t seen a problem quite like this before. However, Hamster has a good group of guys working for them and they were sure it was something they could figure out.

ACME and Hamster agree to work together based on an estimate with no basis in reality. This is their first mistake. The team at Hamster assumed it would be simple enough to modify some existing software to meet their needs and provided an estimate based on those assumptions.

In the beginning, Hamster is able to make amazing progress along the design that ACME agreed to. For a while, it actually appears that they’ll be able to meet the budget as originally designed.

Except for the bugs.

It started small at first, and given the blistering pace that Hamster was able to set, ACME understood that software in development isn’t going to be perfect. They were excited to start using it and it was already a better solution for the problems they’d been having so it was deemed good enough to go into live use, despite the bugs.

But, the guys at Hamster Software are smart. None of the bugs were there on purpose, but because their development process consists solely of identifying problems and then writing code to fix them, sometimes it was easy for unexpected things to happen (the bugs). As they progressed and the project grew, it became more difficult to remember the reasons behind all of the decisions in the code, but they’re all smart guys, so it’s nothing they can’t handle.

Richard Hammond, one of Hamster Software’s founding partners was a great developer who has made big contributions to the project. One day, Richard gets a job offer from Fifth Speed, a very prominent software company, that he just can’t refuse. The Hamster team is upset, but there’s nothing they can do so they continue without him.

If bugs were an issue before, Richard’s absence added jet fuel to the flames. He had held much of the knowledge of how everything worked in his head and now the software needed to be finished without him. It was beginning to show that something wasn’t working in the way Hamster builds software.

The bugs multiplied. Every new release seemed to break more and more of work that had been previously completed.

The specification documents were the only source of reference for what the project was supposed to do and by now had grown so lengthy that it was impossible for any one person to handle.

ACME’s goal of a solution for their widget problems seemed just out of reach. Each new release was a step forward and a step backwards. Now that they were using the system to power their business, the bugs not only affected ACME’s employees, but also their customers.

The bugs were contributing to a loss of real business value. Sure, the software solved ACME’s original problems, but it introduced others and it wasn’t able to change with the business. This grand system that was supposed to solve all ACME’s problems looked more like a liability than an asset. It continues to consume massive amounts of money to maintain each month and no end is in sight.

Sadly, this is the state of many software projects today. Poor planning, inaccurate estimates, and a never-ending stream of “maintenance” combine to make the world of software development pretty daunting for serious projects.

Only by working together can we as an industry strive to improve the problems related to estimates and unrealistic expectations of software projects.

Always strive to understand problems before you attempt to solve them.

Always test your code, if not for you, then for the next guy to work with what you’ve written.

Build Better Software is a service of Reenhanced designed to help developers improve the quality of their code by adding an automated test suite to an existing software project.