Why the developer elites are wrong...

There's an old adage: "Don't fix broken code, rewrite it". This is a simple saying, and it is certainly true that there are many, many times when it is sage advice. However, it assumes that the party in question knows that the code is, in fact "broken".

Examples of broken code has traditionally included, code that is buggy, difficult to read and therefore difficult to maintain. It was later expanded to include code that doesn't adhere to solid design principles, such as when it doesn't satisfy object-orientation methodologies, fails to incorporate design principles such as separating business logic from presentation, etc.

In the Delphi world, one example of "broken code" that is popular is "code under the button". Much VB and Delphi code suffers from this. A RAD environment lends itself to the coding technique of plopping a control on a form, hooking an event, and writing a short novel in the event handler.

Naturally as the application grows, and becomes "legacy", this code gets harder and harder to maintain. At some point during this process, enter the C#/Java guy. He looks at the "legacy" Delphi code, rolls his eyes, denounces every Delphi developer in the world as a no good hack without solid coding skills, pronounces the entire application "broken" and decrees that the only solution is to throw it in the trash and write it from scratch using Visual Studio.NET and C#.

Management is fed a steady diet of propaganda from both ends. On one end you have these Java/C# guys just dying to re-write the application in a 'real' language and use all the latest toys to do it. Their "Design Patterns" books are ready, they have Visio UML diagrams ready to roll, and firmly believe that if Microsoft has put it in "Patterns and Practices", only a complete idiot (such as a Delphi programmer) would dare resist the purifying fire and the march to follow Redmond into whatever abyss it has planned for we mortals. On the other end, you have Management. You know them, the guys who used to buy IBM to avoid getting fired and now want to buy Microsoft for the same reason. These are the guys that will tell you they can't find any good Delphi developers locally, and then begin a nationwide job search for C++ programmers.

The qualifications to get one of these jobs are simple: 1. Believe everything Microsoft tells you. 2. Insist that there is no point to doing anything more with the existing code base. 3. Insist that any developer who doesn't wish to write the new app from scratch in Visual Studio be shown the door. 4. Roll your eyes at anyone who asks what the business case for the re-write is, and make it clear that no one with ANY intelligence would ask such a stupid question.

The other qualification is the ability to use the "legacy code" as a reason why the new shiny .net application is 6 months behind schedule and doesn't do even a 10th of what the previous "broken" code did. Your ability to tapdance in front of management is very important, as it will save you your job and allow you to insist that the remaining "Delphi guys" continue to do maintenance releases on the legacy code to keep the paychecks coming while you write the grand masterpiece of .net development.

You might think, having read this far, that I am some kind of luddite .net hater. Nothing could be further from the truth. I've been writing applications in C# for a few years now, and it has a lot to say for it. There are many benefits to moving application development to .net as soon as reasonably possible.

However, there is a distinct "Out with the old, in with the new" attitude that I am seeing in the development community, and a distinct lack of pragmatism.

In a recent reviews of BDS 2006 from Borland, which supplies users with C#, Delphi Win32, Delphi.NET and C++ development tools, I've seen comments to the effect that Delphi is only good for Win32 development. VCL.NET, it is said, is no good, and it's not worth bringing legacy code forward. Further, the reasoning goes, you need to move to C# to develop .net and just toss Delphi out the window. Don't port….rewrite.

If we have a nice fat sugar daddy willing to finance a complete re-write, no need to maintain the application, and there was some tangible benefit to the re-write that just could not be had ANY other way, I might be inclined to agree.

Unfortunately, it seems that biases and political factors account for more of the decision than the pragmatic arguments about how best to achieve goals.

The case against VCL.NET makes for a good example of this. In a recent project, I was dealing with a developer who stubbornly refused to touch our main application, written in Delphi, and which was written back in the mid'90's originally when Delphi was really hot. He wanted nothing to do with it, at all. He wanted it all tossed and re-written in C# using (of course) Visual Studio.

Now, we were understaffed and needed to keep our IT Department's applications running 24/7 through this process. There was just not going to be the available schedule and budget for a complete re-write. The alternative is to despair and just resign oneself to continually maintaining an ancient Delphi code base.

But since Delphi 2005 (and now 2006) has come out, I have used its refactoring menu HEAVILY to clean up existing code, turn 'under the button' code into business objects, moved code into stored procedures, separated the presentation from the business objects and so on. The Refactoring support in the current versions of Delphi (or Borland Development Studio if you will), do an awesome job at this. I'm slicing and dicing this code so its own mother couldn't recognize it, and addressing many of the complaints of the naysayers that just wanted it scrapped, and during the entire time, the software KEEPS WORKING. The people trying to pitch Delphi code into the nearest garbage can have apparently never read "Refactoring" by Fowler.

Further, much of what constitutes a Delphi app in VCL is portable to VCL.NET. By using Refactoring and the Together modeling surface in BDS2006, I extracted a complete model of our customer, accounts, locations, billing information, etc all to its own unit and added business logic where necessary. Without breaking any of the current Win32 VCL code, we now have a set of related business objects representing our customers. To prove a point to the C# bigot, I rebuilt the VCL unit into a 100% managed .net assembly, and wrote a demonstration C# application which uses that assembly to create and manipulate one of our customer records and all its related data.

It's easy to see how all the business logic and data access could be left in VCL/VCL.NET and rebuilt to be targeted as an assembly or a Win32 package and used by both the existing Win32 application or any C#/.net application we wish, with a single source file and few, if any, conditional defines to separate code branches. Thus, a bridge to .net is built. The chunks of important business code which have always worked fine and do not need to be re-written can be repackaged in such an environment and delivered to any .NET consumer as an assembly. Any bugs we find against the current code base will be fixed in the current source file and propogate to both .net and Win32 clients. The code passes PEVerify as perfectly well behaved managed code, the classes are easily used by C# applications written in either .net 1.1 or .net 2.0 and the business can keep on running as the code is smoothly migrated from Win32 to .NET.

All of this is only possible because of Delphi.net and VCL.NET. Microsoft has NO ANSWER for legacy application development. Their new Team System requires third parties to write plug-ins, or you just need to use it with your Visual Studio applications. Microsoft's story, as it was in the case of VB6 is "start over" and it is amazing to me how many otherwise intelligent coders (and managers) are swallowing the bait. It's hard not to shake my head in wry amusement as I see one company after another go for the "re-write it in C#" approach, and 1-2 years later, still be nowhere NEAR delivering a finished product, whereas those 'idiots' with the Delphi 2005/6 refactor their code into something pretty, and rebuild it as .net whenever it suits their business to do so.

Maybe all of this reads like I'm shilling for Borland and Delphi.NET/VCL.NET. There may be something to this. But unlike the people I'm talking about, I seriously like writing applications in C# with FCL and do so for many new applications (note the word "new"). I'm not blasting people for not developing new applications in C# against FCL. I'm saying that those who make important development decisions based upon those biases and elitism, do so to the detriment of their businesses.

My suggestion: If you have to cross the gulf to .NET, build a bridge to it, don't try to grow wings.