Hello, this article is part of my Death by 1000 Cuts series that shines shine a light on glaring software development industry problems. I'm confident you'll find 1000 articles someday.
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 must take full responsibility for the solutions they produce. It isn’t a user’s fault if you bet on the wrong API, and you’re unable to deliver working features. It’s untenable that users are 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.
Solutions
- 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 with a different vendor, then take on the burden of building and keeping that vendor bridge intact to build redundancy.