In my many years as a technology professional, one of the worst trends I have observed is the preference for the quick fix. This is the patch, the work-around, the extra step or two that compensates for an otherwise flawed process.
There is an old adage that suggests there is never enough time to do it right, but there is always enough time to do it over. This is clearly now the order of the day.
How many times does a road crew have to fill the same pothole before realizing the street has to be repaved? We have become so adept at creating ways of avoiding problems, we forget to back and fix their root cause. One of my favorite road signs is the one that says BUMP ahead. If you know there is a bump, don't hang a sign, fix it!
This mindset carries over into technology. Apparently it is easier to dump raw data into a spreadsheet and massage it until all the missing or incorrect values have been resolved. But do we ever take the time to track back to the source of the bad data and put new processes in place to avoid storing them in the first place? No, instead we dump the same flawed data month after month into a spreadsheet. In fact, we build macros to automate the correction process.
I've observed in some of the new programming tools we have lost the ability to check a return code. Those of you who may have written programs will recall these special variables set to specific values after an operation. A return code of zero (0) usually meant success, while other values would indicate a reason for the failure. Looking at these codes would enable you to take the appropriate action to recover from the failure or warn of bad results.
Even if error codes are available, often it appears they are not being used. It makes me wonder if error checking gone the way of memory optimization. Now it only matters that the process ends, whether it did what it was supposed to or not.
An employee of mine many years ago reported that he had completed his assignment to write a piece of code. He had entered and compiled it successfully, loaded and executed it. It ran, he told me, so he was done. He then went on to mention it produced the wrong results, but he still considered his assignment complete. You can't make this stuff up.
We have to return to the discipline of getting it right the first time, or addressing the source of problems. Let's not continue to focus on mitigating the symptoms, let's instead get in there and cure the underlying disease.
Captain Joe
Follow me on Twitter @JPuglisiLLC
Good article. The problem as I see it is cost in time and money. Here's the analogy. I used to work heavy and highway and build roads and a few more things.It takes a lot of money and time to repair even a simple pothole and that'e where the time and money come in. To repair that pothole it has to be dug up and cleaned out and the new stone and just regular dirt from whatever quarry it might be that produces what is called modified and this will take time and then it has to be re-blacktopped. To do all that the road or area has to be closed off and traffic either stopped or re-routed.That irritates drivers and in turn costs more money and time.
ReplyDeleteI'd hazard a guess and say the same things are true for programming and updating whatever it is you are trying to do.
You would be right, my scarily named friend. But the systems analogy would be to erect a barrier directing people around the broken stretch of road, across a hastily cleared dirt path. This would require a free car wash to be provided at the other end of the makeshift detour. This, in turn, would lead to the need for a laundry service to clean the towels, taxing the water and power systems in the area leading to a utility upgrade, and so on. When we fail to cure the root cause in systems, we ultimately add more and more cost and complexity in small chunks, rather than bite the bullet and suffer the one time cost of the proper repair. Who suffers more in the long run?
Delete