How do you deal with clients who cannot wait for a feature to exist? [duplicate]

Question

I'm maintaining a legacy application that interacts with an ERP. The ERP has a lot of cool features. One goal of the legacy application is to store preparatory data to be sent to the ERP, but also keep the data up-to-date based on what happens in the ERP. A two-way synchronization.

Sadly, the legacy application does not implement all the features of the ERP for the bits it needs to synchronize. But that did/does not prevent the business from using all the ERP features and then demanding that the legacy application remain synchronized.

The differences are structural and not simple to implement in the legacy application. The business does not care about the issue because it's dealt with by the developers who have to cram data in a structure not meant for it, leading to many bugs and being forced to break data integrity rules in the DB (which impacts the business in return but in such indirect ways that they don't get it, no matter how many times it's explained). The business has better priorities.

In the given situation, would it be a moral and/or professional duty to prevent this from happening further to preserve what little data integrity is left and start going down a cleaner road, or should the business's decision be the end all be all?

In case stopping the madness is the right thing to do, how would one go about it? Knowing that in the current context, it seems impossibly hard to say "no, the software cannot deal with this, stop trying to fit square pegs in round holes". The business is extremely frigid at the idea of developers spending time on making things structured and safe since it doesn't give them anything new (functionality-wise) to chew on. It's interpreted as wasted time basically.

Answer 1

This is a classic "you're making bad decisions with your life that effect my life" situation.

You can (and probably should) surface the problem to business managers at every opportunity. Express how difficult further feature-adds are, and the additional cost/risk associated with continuing with the broken underpinnings. When features are requested that strictly cannot be added because of the problem, highlight those as a motivation to spend more energy and attention on the underpinnings.

But... There is no magic here. You cannot get people to want to eat only healthy foods, exercise frequently, or pay attention to the plumbing of their infrastructure if they uniformly refuse to take those requirement seriously. The best that you can do is keep the issue alive: raise awareness, explain the implications, and correlate the increased time/cost/risks they're facing because of the failure to improve underlying infrastructure. Look for allies and receptive ears. Individuals who are newly hired or appointed to influential positions are good candidates as change agents, if you can get them on-side. Lather, rinse, repeat.

At the end of the day, it is their system, their costs, their risks to manage. You can advocate, but technical staff are rarely in a position to make major invest/no-invest decisions. So keep fighting the good fight; keep working to sway those who can start to shift process and investment priorities to address this apparently large and rising tide of technical debt.