“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 high numbers of bugs, or bugs with unusually nasty side effects, your intuition might be correct: something is amiss in your organization.
Customer Impact
Bugs are one thing, but what if you have issues that deeply and directly impact customers? Here are some examples:
- 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.
- 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, your QA process is broken, or your release process may be broken.
- Customers can’t understand the software
- You need examine your product team, your user interface design team, or both. The product does not match the customer business process, and your complexity is likely too high.
To mitigate customer impact, you need to make sure your technical team is aligned to the size and complexity of your target customer persona. If your customers have trouble using your software, you probably need some business analysis or user-experience design help.
Summary
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.