Let me demonstrate with a simple example.
Years ago, I wrote a really simple program for a client. It was a logging application that helped them track incoming and outgoing jobs.
Didn’t do much more than that.
They were… let’s say… “budget challenged”. Well, not really, they just didn’t like spending money on IT. So I did the absolute minimum to make it work, but it worked well, and they were happy.
But, like any software, it evolved over the years. I kept adding pieces to it and changing the logic, and every time I made a change I tested the whole system manually.
The first version only took a few minutes to test – it was that simple. Later versions took a couple hours because of the more complex logic (if Field A is filled out, Field B is required, and Field C has to be blank, etc.).
If the software had stayed simple, unit tests wouldn’t have mattered. But almost no software stays simple for long. The more it gets used, the more the client wants it to do.
By the time I finished with that client, it was taking more time to test the application than it took to make the simple updates they wanted.
Unit tests would have taken extra time to create up front, but would have saved many more hours during the maintenance phase of the project. If I had insisted on building the software properly from the start, I wouldn’t have had to test the entire application for every update.
That time could have been used to add more features instead.
Many (most?) clients see unit tests as an unnecessary expense, but in the long run it saves countless hours, even on simple applications. A relatively small investment up front pays off big over the years.
That doesn’t mean every client will accept our logic, but all we can do is explain it to them in terms they can understand – dollars.
They can choose to ignore our advice, but at least they were given the information.
Of course, it’s better to work with clients who value your expertise and opinion in the first place, but that’s a topic for a future post.