Every day of our lives, be it professional or personal, we’ve got to deal with situations that require us to deal with it now with quick solutions or come up with a better solution and taking the time to implement it to minimise long term pain.

Ideally, there should be a balance between the two but reality tends to force us into coming up with an immediate solution to deal with the current pain. Usually, it’s because someone above you, your customer or that a life depends on it made the issue a high priority.

And it takes someone with experience in certain situation to be able to make a decision that seemingly strike a balance.

As a software creator (I don’t call myself an engineer or developer but that’s a story for another day), I lost count of the times when I have to sacrifice the solution that’s good in the long run to deal with something that the customer wants it now. And then there’s always this “we are behind schedule” speech by the management. So much so, it makes you want to roll your eyes. It can make one feel like the management is always reacting to something and not preempting and executing on a plan.

Of course, perspective matters here. More time spent in doing something means more money spent. The manpower could be better utilised to work on something else that deliver on more value (money) to the company. Not to mention, to the customer, it’s like they don’t get their money worth of goods or services on time.

However, cutting corners on a solution just so that you can deliver on time can lead to long term pain that ultimately translate to time and money wasted.

Let’s take something that I’ve experienced at work as an example.

The system my team and I are working on requires a constant patching of data in the database. It can be either to insert new records or to fix old records with updated information. As the system is still undergoing development and deployment, the data is constantly in flux. And the customer will send us spreadsheets of data for us to do matching and patching.

And instead of spending maybe a week to build the user interface and implement the business logic that not only validates the data but to allow us to upload those spreadsheets and update the database in a few clicks and change existing data all from one UI window, my colleagues have to take the time to review through those spreadsheets. Sometimes, two persons are involved. What any one of them will do is use their eyeballs to scan through the records in order to determine whether to match and update existing records or to insert. Then they will manually write the SQL scripts to insert or update the data into the database.

No doubt the scripts run fast and the database will be patched within seconds.

However, what the project lead and management didn’t take into account of the time and effort needed to validate the data manually every time, prepare the scripts and run them. And that’s not forgetting humans can make mistakes. If the data is patched wrongly, the whole system may not work as intended and then we will need to “rush” someone down to the customer office to fix that issue. Time spent at customer office is time not spent on delivering features.

And if you are someone who panics very easily, and you have to deal with such high pressured situation, more mistakes will happen.

The management of course have a defence. Their stance is that this kind of data patching doesn’t happen often. By my last count, it has happened five times since the project started and we aren’t even at the end yet. And I suspect this data patching will repeat several more times until the end of the project. How many more, I don’t know. In fact, I’ve just recently spent half an hour to de-associate the relationships between two datasets because it wasn’t patched properly. Mind you, those de-associated relationships need to be rebuild again once the data has been reviewed and cleaned up again.

I may not be in a management role but it’s obvious to me that taking the time to build that user interface and implement the necessary business logic to help us match the data, validate the data and update the database in as few click as possible is the better option here.

And given what I know about the future plans of the company with regard to this project, the current way of doing things is just not scalable. Oh, I raised the point a lot of times but I’m always overwritten. Well, mostly.

This is what I mean by meeting short goal or minimising long term pain. There are many other examples that I could think of but this is the clearest one to me.

In conclusion, always strive for the mid-point between meeting short term goal and minimising long term pain by evaluating as much data point as possible before making a decision. It’s especially the case if it’s something that affects your persona life and you don’t have a higher up to answer to. And depending on the culture of where you live and work, you can either fight to the death for what you believe to be the right course, find a compromise or swallow your pride and let the other party win. In an asian context like the one in Singapore, you are better off choosing the last approach if you are an employee at the bottom of the ladder or an underling. Or management will make your life miserable.