We as programmers/developers/engineers (call yourself whatever you want) solve problems daily, correct?
If your answer was “of course”, here’s a cookie. If not, you are probably one of those people who dislike a youtube video for no apparent reason.
Now that we cleared that up let’s get on with our business. So yes, we solve problems every day, may it be a bug in our software or defining a new feature, either way, we solve a problem in both scenarios. But are we sure that we tackle our problems correctly? Let me tell you a story that did not happen in real life and is purely fictional. Sarcasm? Maybe, maybe not, you’ll never know…
Well, there was a company developing an application, and one of its many features was to view salaries by downloading a PDF file containing your salary info. The problem their customer had was that more than one user was using a PC and they all used the same username to access it. Although they had the same username for the PC, they all logged into the application with their own credentials. So, what happens if the user forgets to delete the PDF since the contents of those PDF files are very sensitive? To force each user into having, its own PC was not an option. To solve their problem, they added password protection to the downloaded files and each user had its own password with which he or she could open the file.
They solved their problem, right? Well yes and no. Did they protect the sensitive information? Yes, they did, but did they address the root problem? No, they didn’t. So what went wrong? Let me explain…
Well, I would say the information was the problem here, they didn’t try to get more information about how their customers were using their application. The most important question was: “Why were they downloading the PDFs?” The answer to that question is that the application doesn’t offer any other way to view salaries than to download the PDF and open it. The way they solved their problem was actually creating a workaround that was not needed, and with that fix, they added a new layer of complexity to their application, since now every user also had to remember that file’s password. Sure in software business the impact of not solving a problem correctly might not necessary be a life or death situation, but there are still consequences.
Now with that fix, they might need to support new features around that, which might introduce new problems to solve. Along with supporting that feature they might finally get a feature request to be able to open files in their application as a preview. Once they develop that, they need to support two features instead of just one, which means a bigger backlog/todo list and that actually costs the company. And we all know what a company with cost inefficiencies becomes…
And that is just one of the scenarios that might happen in that situation. Do know that there is no such thing as a perfectly solved problem, since you still have a deadline to deliver, and there is no such thing as perfection. But you can at least try to get as close as you can to perfection by getting all the information about the problem you are solving, brainstorm about it with co-workers, research about possible solutions and the outcomes for solutions, etc. You get the drill, right?
I know that sometimes this might be out of your hand since your superior is pressuring you that he wants this done yesterday and that the workaround is the best option for your company. But don’t just give in, try to explain it to them what might happen if you solve it this way. Of course, if everything is on fire you can suggest that you can solve it as a quick fix, but would like to solve this properly as soon as the fire goes out.
The bottom line is that solving problems with workarounds, might seem like a logical choice at the moment, but in the long run, it usually turns out as counter-productive. Especially when your application gets older, you increase the life expectancy of your software application by solving problems properly. What? Software applications have a life expectancy? Yeah, that’s a thing. It’s basically the time span before software is mature enough and ready to be rewritten and maybe ported somewhere else. Don’t believe me? Well, click here to see how many posts there is about it.
All this rambling might be obvious to you, but it isn’t to everyone. Well, I think I covered what I wanted, so I hope you got something useful out from all of this.