3

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...

Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
leokhorn
  • 614
  • 5
  • 12
  • 6
    You can refuse. And you can be fired. They need the data fixed because they need to run the business. What you need to do is to convince someone in a position to direct development that these interruptions are costing more than just fixing the thing would cost. – Michael Kohne Jul 28 '14 at 12:02
  • 1
    Or that manual database changes could potentially cause a major financial disaster, which fixing the app could prevent – Mawg says reinstate Monica Dec 22 '16 at 15:58

2 Answers2

8

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.

Julia Hayward
  • 2,872
  • 2
  • 15
  • 12
  • 5
    There's also possibly the issue of bypassing audit trails. Depending on the field you are in, this could be anywhere between a minor inconvenience and a legal minefield. – Julia Hayward Jul 28 '14 at 14:46
  • Absolutely - document the hell out of every fix, do a screen recording etc – Alan B Jul 29 '14 at 08:27
  • 3
    1.5 years later, stats from our ticketing tool were ultimately noted. They did show we spent one third to one half of our time fixing data or bugs. We were given time to create a tool to auto-fix the most common case when it occurs. One case down, fifty more to go. – leokhorn Feb 04 '16 at 15:50
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
Tulains Córdova
  • 39,201
  • 12
  • 97
  • 154
  • I fear we're also understaffed to the point where it's an either/or thing: either I fix data by hand or I fix the code that produces data errors. Sigh. – leokhorn Jul 28 '14 at 14:46
  • @leokhorn An alternative is that the person doesn't need to be a developer. – Tulains Córdova Jul 28 '14 at 15:28
  • Still seems to either require hiring someone, or pulling someone from something else. In both cases, training said person to do proper data checking. I'm pretty sure this won't fly in my context, but it's a nice idea in general. – leokhorn Jul 28 '14 at 15:55
  • @leokhorn It looks like a good oportunity for someone who is fed up of programming. – Tulains Córdova Jul 28 '14 at 16:21
  • @leokhorn I added a second alternative to my original answer. – Tulains Córdova Jul 28 '14 at 19:59