Young beautiful lady expresses anger and fury sitting in front of large computer screen. Smart casual dress, beige office desk, wireless keyboard and mouse, light grey background

Business: Why Your Software Sucks


“What do you mean the server went down?” asks the CEO.  “It has been happening every week” the lead tech says. “It didn’t do that for the other customers,” laments the CEO.  The tech replies “This customer is ten thousand times larger than all the other customers combined. We didn’t build the application to handle that volume of data.”

The enraged CEO berates the tech. “Well, why not? What the hell am I paying you guys for??”  Unphased, the tech responds: “It would have helped if we had known you would sell to a customer that large, this soon into the project.”

This is an all too common conversation.  The business side of a software company is unaware of the limits of their own product.  They sell it beyond its operational bounds, and the development organization has to somehow make it work.

But wait a moment.  The business side is not technical.  How could they possibly be expected to understand the limits of their product, or the feasibility of how or to whom they sell it?

This is where I would normally say something like “the technical side has an obligation to protect the business by helping them understand the limits of the product.”

In a perfect world, the business and technical parts of an organization are aligned, transparent, and supportive of each other. But…the world is far from perfect.

So, for my dear readers on the business side, here are some ways to tell when your software is in trouble, regardless of your relationship with the technical side of your organization.

Bugs, Bugs, Bugs

Repeat after me: “Bug-free software is a myth.”  If you don’t believe that, go ask your top tech talent about it.

If a company believes that their software is bug-free, it is likely that they simply aren’t testing it in such a manner that the bugs reveal themselves. There are bugs in every piece of non-trivial software ever produced: aircraft, rockets, ships, cars, web software, you name it.

A properly designed system employs a mixture of technical best practices with organizational best practices to mitigate against negative ramifications of bugs. If the system is not designed properly, you might see behaviors like this:

  • Every release contains a large number of bugs that have your customers hesitant to take new releases
    • This means there are problems in your software design, release processes are broken, and your QA process is broken.
  • When a bug is fixed, it almost always introduces new bugs
    • Either you have a hero programmer, your team does not understand the code, your system has badly designed relationships between components, or all of the above.
  • The same bug keeps re-appearing
    • You have a process problem, or you might have duplicated code in your software.
  • Your cloud costs are much higher than anticipated
    • Your teams are using cloud assets inefficiently, or they are not understanding your current or projected customer size and/or system usage.

Bugs in software are a telling indication of the health of the organization that is producing the software.  If you perceive that you have out of control amounts or behaviors of bugs, something might be wrong.

Customer Impact

Bugs are one thing, but what if you have issues that directly impact customers?  Here are some common challenges:

  • You have outages in production
    • There are problems in your software design, problems in your devops, or you are selling to the customers that are beyond what the software can support.
  • Customer data disappears when you release a new version
    • Your technical side has a problem with database migrations, the QA process is broken, and  the release process may also be broken.
  • Customers can’t understand the software
    • You need examine your product team, your UX team, or both. The product does not match the customer business process, or your complexity is simply too high.

To mitigate customer impact, you need to make sure your technical team is aligned to the size and complexity of customer you are selling to.  If your customers have trouble using your software, you probably need some business analysis or user-experience design help.


You don’t need to be Melvin Conway of Conway’s Law fame to understand that the behavior of your software reflects the condition of your organization and the strength of the relationships between them.  I invite you to actively ensure that your technical and business sides are operating in alignment, so that you never need to contemplate why your software sucks.