Working Software Without Tests is Not Working Software

Posted: April 29, 2013 in Clean Code, Development General, Unit Testing
Tags: , ,

A little while ago I mentioned that in his book Microsoft .Net Architecting Applications for the Enterprise, Dino Esposito says that a working untestable software product is no different than a working testable one; I am paraphrasing, but that the second one will have a better design. I also said that I did not agree with the first part of this statement and I promised that I would expose my arguments so, here we are.

First of all I want to make perfectly clear that I have the highest respect for Mr. Esposito. I believe he is brilliant and every developer who uses Microsoft’s technologies should read as much of his work as possible. So with that out of the way, let’s begin.

I believe that a software product is a living organism that after it is born it grows, changes, reacts to external stimuli, it can even reproduce in the form of other software that uses some of its components. Of course it cannot do it by itself, it is us the developers who make that happen and of course, we do not do it because we have nothing better to do, we do it because someone asked for it. The important thing to keep in mind is that whoever requested the work to be done on that software needs it for one of two reasons: to make money or to save money.

Our customers embark themselves on the arduous, painful, and stressful activity of sponsoring a software product because they have a specific business need and they hope that their new or enhanced software will eventually produce an increase in sales or profit, an increase in productivity, an improvement of their processes, or something of the sort which in the end it just drills down to making or saving money.

To illustrate this let’s imagine there are two competing companies that have a software product which provides all kinds of academic support to schools and universities. It turns out there is a new trend among universities which provides an amazing business opportunity to these companies but they need to enhance and add new features to their products in order to support it. Both products have been developed in-house and they still have their original teams working for these companies so all the developers know their respective code inside out. Both products work well and their code bases are reasonably clean.

After just a few months the first company has implemented just enough of the new features in order to provide the new services. They were able to do it quickly because every time a modification was ready their automated tests told them right away which existing features would break so the issues were dealt with immediately and the QA team did minimal regression testing so they could focus on testing deeply the new requirements.

On the other hand, the second company is still struggling with their release. Every time a new feature is checked in, the QA team needs to spend a few days on a full regression testing effort and when they find either something that broke or a defect on the new features the code goes back to the dev team, of course, which spends a few days figuring out how is it that the new feature broke the old one and how they can make both of them coexist.

Eventually the second company releases its product. Unfortunately their competitor’s has been around for some time now and they have been able to keep their existing customers, get new ones and even take a few of their competitor’s ones.

As you can see, in this fairy tale which can very well happen in the real world, both companies had a working software product, I never said that neither of them had a mess in their code quite the opposite, the only difference was that the first one was designed for testability and had a good suite of tests. Their product helped them to increase their sales so its main objective was fulfilled. The second company since they could not get their product to market quickly enough, lost market share, lost sales and the big investment on their software will be recovered later, if at all.

And there you have it, even though the second company had a working software product, in the end, it did not work for their benefit so do yourselves and your employers or customers a huge business favor and be sure to insist on designing the product with testability in mind and having a great suite of tests to protect it.

Advertisements

Does this make sense to you?

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s