The “there are more important things to do” fallacy

Occasionally when people are discussing the merits of software quality, someone will chime in and say something along the lines of “if it isn’t billable, there are more important things to do”.  In this article I’m going to break down why this argument is a fallacy.  It’s my belief that improving the software quality is just as important as billable hours and new features.  I’m going to tell you why:

First, I’m going to address the billable hours.  Billable hours are more important than quality if you work in a vacuum, but nobody works in a vacuum.  Poor quality software is going to slow you down relative to your competitors.  This sluggishness can get so bad that customers notice. When that happens they’ll second guess working with you in the future and referring you to others.

As for focusing on features, that is analogous to focusing solely on your company’s revenue.  Revenue is not nearly as important as your profit.  Profit is what you get to take home and spend at the end of the day. It works as a simple equation:  profit = revenue - cost .  As you can see, there are two ways to improve your profit: You can increase revenue or you can reduce cost.  Software quality is all about reducing cost.  As such, it’s just as viable and important to your success as increasing revenue.

Quality keeps you moving forward and reduces time spent backtracking.  Are you constantly revisiting “finished” features because you realize that they have bugs in them?  That is backtracking.  This concept applies to industries outside of software.  To use an analogy, if a car company ignores quality, some day they are going to have to issue a recall when their product has a serious issue.  When this occurs, it is always an expensive PR nightmare.

Another thing people frequently say is that “quality isn’t important because the customer can’t tell the difference”.  I don’t agree with this.  In my experience, poor quality software has a lot of bugs that customers do notice.  When this happens, customers are fearful of upgrading.  When they refuse to upgrade, it puts extra burden on the company because you have to maintain many versions of the software simultaneously.

When people say “quality isn’t important because the customer can’t tell the difference”, they probably imagine a product that looks fine on the outside, but is very poor quality under the hood.  I’ll humor this idea:

Lets say that from the outside, two identical applications were built but one was objectively worse from a quality perspective.  Does that mean both development methods are equal?  No, they are not equal because efficiency matters.  Applications are easier to maintain when they consist of higher quality code.  That means when you want to add a feature to both tomorrow, it will almost always be easier to do it in the application with higher quality.

When you cut corners in software for short term gains, it’s called “Technical Debt“.  Just like financial debt, it can be advantageous sometimes but if you don’t pay it off, it will be expensive.  e.g., Banks charge interest for their loans.  In software, you may save yourself a few hours by cutting corners, but years down the line that same part of the code may take months to refactor when you just can’t avoid it anymore.

High quality is like investing in a stock that pays dividends.  You have to pay to own the stock, but every month it’s going to pay you back and that payment can actually compound on itself.  For example, imagine you write a great test at the beginning of a project’s lifetime and for years to come you can be confident that that piece of functionality still works.  That is a great investment.  Compare that to the projects that have no automated tests.  People have to cross their fingers every time they change anything because they have no idea if the code broke in an unexpected way.  High quality software makes you more efficient.

Efficiency matters and businessmen have known this for years.  That’s why Henry Ford implemented the assembly line.  Imagine if Henry Ford thought that this effort was pointless because the car is the same to the customer either way.  Fortunately for the Ford Motor Company, he knew that there is more to a product than what the customer sees.  Because Henry Ford focused on the process of building a car, he was able to build a new Model T every 93 minutes.  Could the customer tell that it took 93 minutes instead of 4 days?  Probably not, but the efficiency of the assembly line gave the Ford Motor Company a competitive advantage in the same way that higher quality software will give your company a competitive advantage.

Join the email list for bonus content.

2 thoughts on “The “there are more important things to do” fallacy

  1. Atul says:

    Hi Daniel,
    I simply loved the post! You touched a chord! Quality code runs well in the field – and reduces overall cost…
    The underlying problem is understanding I think ;-) One needs to be in the trenches – to see the value of quality code…
    I know places where they don’t want to hear about any mocking frameworks…
    The value refactoring brings to the table is also little understood…
    There is too much of “reinventing of the wheel” mindset out there…

Leave a Reply

Your email address will not be published. Required fields are marked *