I’ve never been more motivated to quit than when on the other side of this. The thing that already exists only seems from a distance like it does what I need. It makes different trade offs, it’s poor quality, the team that owns it is far away, and they “agree in principle” with all my proposed changes but “it’s a question of resources.” On smaller projects I have sucked it up, and wow. Something special about tying yourself up in knots to do work you’re ashamed of in the end.
On the bigger projects I’ve always managed to wriggle out, thank god. Usually by building something domain specific so as to avoid the appearance of direct competition. Language and branding are crucial here. If your design doc uses the words “rules engine” half the company perks up. Why aren’t you using ours? On the other hand “configuration” is totally fine.
I'm hopeful that if people were to look at the same data the teams would not have such vastly different ideas about what problem they are trying to solve. I presume that these organizations generate overlapping products because they don't communicate, but shared data is a kind of top-down communication which works even if the teams feel that they can not coordinate.
Generally the existing system is appropriate to the business context it was first built for. The problem is that the owning team would like to claim the “impact” of you reusing their solution in a new domain, while maintaining a “not my problem” disposition towards the unique constraints of your domain, and towards the daily ergonomics of your life in their codebase. What’s needed is a proper platform team that can serve both customers.
On the bigger projects I’ve always managed to wriggle out, thank god. Usually by building something domain specific so as to avoid the appearance of direct competition. Language and branding are crucial here. If your design doc uses the words “rules engine” half the company perks up. Why aren’t you using ours? On the other hand “configuration” is totally fine.