Coding a Mile in Someone Else's Market

It is easy to look at legacy software systems written by others and criticize the design and implementation. I'm not proud to admit it, but I've done this myself through the years. Time and experience have allowed me to appreciate the difficulties inherent in building software in an ever changing world.

Consider 10 years ago.

What technology were you using? We had just come out of the Y2K scare, the web was still about "eyeballs", and Silverlight and the iPhone were years away. You had Java as your main option for writing web applications (which I'm not sure were called web applications).

Were the applications written then bad because they aren't using Entity Frameworks and Service Composition? Of course not. Smart people were using the latest and greatest patterns (Gang of Four, anyone?) and practices (eXtreme Programming).

It is interesting to approach "legacy" applications from a historical perspective. What was the state of technology when they were written? What was the state of the market they were serving? How has that market changed over time?

You may find it interesting that these are the same questions you ought to be asking about technology, your application, and your market today.

The bottom line is this: It's hard to write software. Period. You have to handle today's problem. You have to anticipate what the market may need in the future. And more often than not, you are tied to customers who are using your current product.

Instead of re-writing an application, consider extending it by adopting newer technologies for new features. You may have to write some adapter code, but that may be easier than re-writing a bunch of functionality that works fine today. For example, I managed a project that integrated C# WinForms into a Delphi application. We extended integration and other processing by surrounding the core Delphi engine with .NET web services. We saved a lot of time not re-writing and regressing testing code that worked.

I'm not saying don't rewrite applications. What I am saying is that you should make sure you are doing it for sound business reasons, not just to move to newer technology for the sake of new technology.

Keep this in mind: That hot Silverlight application you are writing today will be someone else's legacy application in five years.