If you've managed software developers long enough you've heard this phrase: "That code is old, we should replace it." In fact, I'm sure you've heard it more times than you can count: if you had a nickel... well you get the idea. Is old code bad? Should it be replaced? Where does the prejudice come from that makes developers believe that any code older than their latest cell phone needs to be replaced?
Most developers believe that their code is better than everyone else's. This is not altogether bad. A good manager wants developers that are sure of themselves. We ask them to solve very difficult problems, in a foreign language, using a mix of theory and creativity that only a small percentage of the population can understand. The benefit to this confidence is that the majority of the time they solve the problem. The detriment to this confidence is that it usually takes them longer than they expect. There's a good reason that project plans aren't based on developer estimates because they're usually wrong.
Of course there is more to it than that. Good custom software development is HARD. Anyone can write some code that calculates sales tax for a couple transactions. It takes a special group to write a similar application that works across the world and can perform calculations 500,000 times a minute. The kind of developers that can do that are rare and their code will stand the test of time. At Amadeus Consulting, those developers are called Architects because they do more than just develop software, they "architect" platforms.
A software development platform is an attempt to provide the best of both worlds. At the core a platform provides a set of functionality written to scale and be expanded. The principle here is that once the main functions have been created, tested and proven in the field you should not have to deal with them again. However, every client is different and will put their spin on a project. This is where the creativity and ability of developers should be applied. Having an expandable platform allows developers to customize in order to meet the client's needs without jeopardizing the core business functionality. The sales tax example is a good one. Once you nail that you shouldn't write it again. How much money will it cost your company if the next developer comes along and makes an error? You could be left with a big tax bill at the end of the year for no other reason than that developer was sure their way was a better way. We have developed platforms over the years that support application development solutions including e-commerce, content management (CMS), client relationship management (CRM) and business intelligence. These platforms were architected and continue to stand the test of time.
As a Director I have to be pragmatic about code. Sometimes we should write it from scratch, sometimes we should use a third-party tool and most of the time we should use our own platform. When it comes to custom application development, meshing business need, budget, scope and schedule with the best tools available is why our customers have come to rely on us and why they come back time after time. Is old code bad code? Old code is just old, but poorly written code will always be a problem. I'd rather base my business on old code that was well architected than the latest thing that was poorly written.
-Josh Turpen, Director of Client Engagement
Go to Josh's Profile