Listen to this post
In the article Death by 1000 Cuts, I summarized the current state of software quality. I mentioned that we are all experiencing issues daily, and it’s wearing us down.
Have you ever been stuck in whodunit limbo, wedged in between two companies with no way out? One company says their product no longer works because another company broke theirs. These days it’s usually a large company that breaks the product you’re using due to an API policy change. In the old days, it was two companies that refused to admit they were responsible for their software failures. What a counterproductive place to be, and it’s not your fault.
Software developers need to take full responsibility for the solutions they produce. It isn’t a user’s fault if you bet on the wrong API, and now, you’re unable to deliver working features. It’s untenable that users are always put in this position daily. This position has bitten me in the past as a user and a developer. It’s not a fun place to be.
Users shouldn’t be responsible for fixing your software problems. If your users need to contact another company to fix a problem with your software, you’ve failed miserably. It isn’t the user’s fault, and there are no excuses. Learn to design better systems that don’t introduce a single point of failure as a feature.
- Don’t put all your eggs in one basket. If your software solely depends on one vendor’s API reconsider your design
- Directly engage with the vendor that is causing issues for your software. Make sure you have a way to influence the vendor and resolve problems. Ideally, use open source products and avoid the vendor problem altogether.
- Determine ways to use alternative vendors to service your users. If a user can meet their use case end to end with a different vendor, then take on the burden of building and keeping that vendor bridge intact to build redundancy.