Once you write a piece of code, expect it to be in production forever. This doesn't mean that it won't be modified, but it does mean that the architectural decisions you make early on in a project can determine to a huge degree the amount of work that will need to go into making modifications in the future.
I once was asked to build a "simple" application that would calculate productivity bonuses, just as a stop gap until IT could build something robust. The platform: Microsoft Access. Arg. I can't harp on Access to much, though. It provides a good place for people inexperienced with enterprise systems to create business applications. The problem is that its not production-ready. It's when Access is used in production worthy, business critical operations that things get hairy. After it was in use for a few months management decided that bonuses would now be based on a percentage of each person's salary instead of using an old methodology. Which meant that the "simple" Access database residing on my laptop would now contain a list of everyone's salary! This was way before the massive data breaches we have seen recently, but that aside, it would only take a hard drive crash, spilled beverage, or power surge to affect the take home pay of all the employees at the company. Oh, and to make things worse, I was an intern at the time...
The point is that once something is built that gets the job done, it makes it that much harder to justify the cost of upgrading due to "technical reasons". The guys in charge of the budget don't care if it's in Access, .NET, or on an mainframe. If it works it works. Unfortunately it sometimes takes a data loss or data breach for management to invest in solid IT hardware and software.
So any time you write a piece of code, think - this could be around forever. It will change the assumptions you make early on and will help to avoid costly mistakes.
No comments:
Post a Comment