I’ve recently started working on a legacy application that frankly doesn’t do all that it should. It’s lacking a lot of features, has barely any administration capacities and doesn’t check half the data it should.
As such, it’s very easy for users to do something stupid and get stuck. “Oops, I added this item of the wrong type to this thingie and now it won’t let me remove it”. Indeed, the application should have checked for this, but allowed adding the wrong item. And now, when it comes to deleting the wrong item, it becomes extremely protective and refuses that anything be removed.
Problem is, the clients (who are actually users within the company) don’t care much for that. They need the application to hold the real-world data as it should be, so they ask the developers to “fix it” by changing the data. In this example, deleting the wrong item. In other cases, it will be reassigning items to different parents, fixing various values, etc…
Since the application has almost no admin GUI, everything ends up being done directly in the database (augh!), risking even more issues down-the-line unless you know exactly how it works (which no one really does considering the massive application).
Ultimately, it feels like the database has become a huge Excel file that devs edit day by day at the whims of the clients, because of failures of the application.
It’s obvious to me that fixing the application to avoid such situations should be top priority, but it seems the clients prefer asking for a lot of new features instead and it’s accepted as such.
What can a developer do in such a situation? Is it even possible to refuse DB edits in favor of fixing things? There are so many bugs that it feels like they’re never going to wait that long…
2
As you’re not in a position to change the policy, what you and colleagues need to do is:
- Document the cost of the policy: the amount of time you spend making fixes in the DB as opposed to developing,
- Document the risk of the policy: the number of times a fix in the DB had unexpected consequences and how severe they were
- Document any other negative consequences – developer attrition, loss of confidence by users etc.
and present it to your immediate managers (you don’t want to be seen to be going over anyone’s head straight to the top in this sort of environment). In an ideal world you’ll already have a support system which tracks this sort of thing but I’m assuming your world is far from ideal! It may make someone see sense, it may not, but in doing so you have fulfilled all your responsibility to the company.
If after that, nothing changes, then I’m afraid you either have to accept the dysfunctional workplace and shrug off all the failings, or move on. When the inevitable crisis happens, a copy of the above in writing will at least cover your back.
3
I’ve seen the exact same situation, and what we did was assigning one person to do only data correction.
That way clients got their data correction requirements done fast, and the rest of developers, freed up from that burden, could fix the app more quickly.
Once most errors that generate bad data were fixed, the person assigned to data correction was assigned back to developing/maintaining.
Is that is prohibitive, then an alternative battlefront could be (based on real-life experience):
- Create motinoring scripts that detect bad data even before the user calls you
- Create scripts that make different types of data correction a breeze
- Create triggers that reject bad inserts or updates (which may also help recreate the bugs), until bugs are fixed
5