Most of us that work in corporate Information Technology shops are Software Archaeologists. Every organization I’ve seen and many I’ve talked to has a built-up layer of legacy applications that are old and in disrepair. While many of these applications are used daily, it may have been years since they were opened, rebuilt, refactored. The source code may be missing, and the original authors may be long gone from the organization, taking their knowledge of the application with them.
It’s this organizational brain-drain that turns many of us in corporate IT into Software Archaeologists. Every time a developer has to don his leather fedora and dive into an ancient codebase with little to guide him but a few cryptic comments littered in the code tomb, and a document that some long-ago intern put together in a half hour to meet a letter-of-the-law requirement in the then-current SDLC, that developer becomes an archaeologist.
Being an archaeologist means digging through all the various eras of coding. Being able to parse the Scatter-Gather patterns in Visual FoxPro, say, or to unwind the data calls from the business objects that were once part of the popular CSLA methodology - those become part of your everyday toolkit. What about that legacy web services architecture that passes around typed data sets everywhere? What about that .NET 1.1 Remoting service layer you built? You need to know it all, and to hop back and forth through the disparate layers, gathering golden icons and dodging rolling boulders all the way.
Even those developers who only develop new applications need to be versed in Software Archaeology, because nowadays many internally developed applications are on end-of-life platforms or hardware, being scoped for moving to the cloud, or are being revisited as part of Business Process Reengineering. These developers need to get back into recently rewritten code and re-envision. You have to know how to dig.
As a Software Archaeologist it pays to know not only today’s architecture, but those of the past, especially those that were popular in the organization around the time the code was written. But not limited to the standard architectures of the day. Organizations hire people who come in to try their hand at something new, or bring in some flavor-of-the-day architecture, tool, library. As a result, one-off applications are going to be unearthed. As architectures become archeological layers in the binary geological strata of an organization, so do architects become archaeologists.
I have a deep appreciation for all my colleagues who perform software archaeology on a daily basis. Those whose jobs are just to maintain those applications that time has forgotten.
I respect the dig.
No comments:
Post a Comment