When it comes to custom development of software/apps, CONTEXT IS KING. Check out this little story from my past that puts everything into perspective.
Is it always good to have software that runs fast?
If anyone is asked this question, it’s not surprising to have “Yes” as the resounding answer. Well, who would choose a slow-running piece of software anyway?
Years ago, I had to learn that a single question like this is never enough basis to decide and make changes to a piece of software. You have to investigate first and dig deep, ask about things like background, purpose, and usage, before you decide to change anything, even for something as simple as speeding up its performance.
Once upon a time, my development team and I made a reporting tool that generated reports for 60 seconds. It did lots of things in the background and merged lots of datasets, but we could still do better than 60 seconds, right?
Yet no user ever complained about it. No one ever asked for upgrades nor maintenance. But still, we took on the task of improving its performance. It was an academic idea–faster is better.
It took us just three hours to do the magic. From 60 seconds, we were able to get it down to one. It’s amazing, right? We’re amazing! However, when we deployed the change, our users weren’t as excited about it. We thought something crazy must be going on because come on, guys! That’s 59 seconds saved!
What we didn’t realize is, this report gets run once annually. Let me repeat: once, annually.
For our user base, the hit of 60 seconds per year was not a problem. Sixty seconds was a small price to pay. Yet we put in three hours of work to speed it up, to “fix” it.
The payback period on those three hours is around 180 years. Someone is paying back our development cost for the next hundred and eighty years because we’re saving them 59 seconds.
I hope this experience of mine will help you avoid making the same mistake. Think about the use case, think about the context, talk to your business analysts, talk to the people on the side of the users–and most of all, ask.