Bandages for Applications

At what point does a “data fix” do more harm than good?  For that matter, what is the tipping point between doing a data fix and fixing the application?  A data fix is merely a bandage for an application.  It treats a symptom, not the problem.

There are many debates about this very topic but let’s get things settled at the beginning:  one data fix is too many.  Yes, that seems rather draconian, but if you need to go into the database and manipulate the data to achieve the correct business results then there is a failure somewhere in the process.  Perhaps it was in gathering the requirements.  Perhaps it was in not providing the correct testing.  Or perhaps it was an unforeseen circumstance.  (The users got access to the applications.  It could happen.)

Data fixes mean that there is a problem, a big problem.  But a big problem for who?  Yes, the application is behaving in a way that wasn’t intended.  Yes, the data that we are processing is fundamentally wrong.  But is it a big problem?  if the data fix can run in a few minutes is it better to do that than fix the application?

There is a common fallacy that a data fix only takes a couple of minutes of effort.  First it was found by someone.  Maybe it was an external client or perhaps an internal client, but either way a real person looked at the data and said “This stinks.  It’s wrong.  it’s garbage.”  They now need to document the problem and bring it to the attention of someone who can fix it.  Or at least relay it on to someone who knows someone who has an idea of the process required to fix it.  And then that work gets prioritized, put in a queue and waits for someone to pick it up, evaluate it and then create whatever is necessary for the data fix.  And then it needs to move into production through whatever process is in place to facilitate data fixes.  After it runs someone needs to identify that the data is fixed, then close the ticket, inform whomever that the problem is resolved  and then the information eventually gets back to the originator of the request.

While it may seem like a 10 minute task, the effort, coordination, tracking, implementation and all the rest takes way more than 10 minutes.  Depending upon the scope of the data fix it could be a lot longer than 10 minutes of work.  But that’s only the cost of repairing the data.  What about the cost of repairing the reputation of the application.  Sure, one data fix doesn’t seem like much, but dozens, hundreds, thousands of data fixes?  Can you imagine the low-level of confidence that people have of the application that requires thousands of data fixes?

An application that requires data fixes to run does more than just chew up people’s time that could be better spent working with the end-user, it lowers the confidence in the application to the point where people may question anything that the application tells them.  An application that you depend on, but don’t trust.  How is that supposed to help the organization as a whole?  If you don’t trust the application would you trust the people who are maintaining the application?  Would you trust the organization that let the application get into such a state in the first place?

A diet of data fixes does more than cost money, it costs lost opportunities, it costs in employee morale, it costs in employee retention.  But more importantly, it emphasizes that perhaps the organization has priorities that are in conflict with the clients of the application.

Leave a Reply