Hello! This article is part of a Death by 1000 Cuts series that shines a light on glaring software development industry failures. I'm confident you'll return to 1000 articles someday.
Are you stuck in whodunit limbo; wedged between companies with no way out?
One company claims its product fails because another company broke theirs.
A company breaks a product with an API policy change. Traditionally two companies refuse to take responsibility for their software failures.
What a counterproductive place to be, and it’s not your fault.
Software development teams must take responsibility for their products. It’s not your fault they bet on the wrong API. It’s untenable that you’re in this position. This position has bitten me before as a user and a developer; it’s not fun.
You aren’t responsible for fixing software problems. If you need to contact another company to fix a problem, software development teams have failed miserably.
Software development teams must design reliable systems.
Solutions For You
- Find a different product.
- Post your problem on the Internet and make some noise!
- Use open-source products and find ways to contribute.
Solutions For Software Development Teams
- Don’t put all your eggs in one basket. If your software solely depends on a vendor’s API, reconsider your design.
- Directly engage with the vendor causing issues with your software. Influence the vendor and resolve problems. Ideally, use open-source products and avoid vendor problems.
- Determine ways to use alternative vendors. Meet their use case with another vendor, then maintain the relationship to build redundancy.
Other Deadly Cuts
- DEATH BY 1000 CUTS
- SOFTWARE DOCUMENTATION GAPS – DEADLY CUT ⓵
- SOFTWARE RELIABILITY – DEADLY CUT ⓶
- THE BLAME GAME – DEADLY CUT ⓷
- DATE DRIVEN DEVELOPMENT – DEADLY CUT ⓸
- TECHNOLOGY KNOW-IT-ALLS – DEADLY CUT ⓹
- MISSING CONTEXT - DEADLY CUT ⓺
- INFORMATION PAYWALLS - DEADLY CUT ⓻
- TECHNICAL OVERCONFIDENCE - DEADLY CUT ⓼