The Legacy Dilemma
By Jonathan Goodyear
If you examine the sugar dish on the table at your favorite restaurant, you ll likely see a plethora of different colored packets. Along with the traditional white packets of pure sugar there are pink packets of Sweet n Low, blue packets of Equal, and now yellow packets of Splenda. Even though the pink, blue, and yellow packets do pretty much the same thing (provide a non-sugar sweetener for beverages), restaurants nonetheless carry all of them. The reason is this: As these various products were introduced to market, they each gained a particular market share. Their customers have grown to depend on a particular brand of sweetener and the restaurant owner doesn t want to alienate any of its customers by not offering their preferred condiment even though one of the others would do the job just as well (if not better). Restaurants must deal with the legacy dilemma of having to support and offer older products and product features for the sake of customer comfort and satisfaction.
The ASP.NET team was confronted with the legacy dilemma when they contemplated how to deal with enhancements to the Web control toolbox in ASP.NET 2.0. For instance, one of the most widely used Web controls in ASP.NET 1.0 and 1.1 is the DataGrid. It is also the most customized Web control. Perhaps a hundred or more articles have been published in established print media, as well as hundreds more online, teaching developers how to hack the DataGrid to do things that it won t do out of the box.
The ASP.NET team wanted to implement the best of these hacked features in a grid control to be released with ASP.NET 2.0. They also wanted the grid control in version 2.0 to integrate seamlessly with the new data provider model (using the various DataSource controls). However, it was also important to minimize the migration impact on developers who were comfortable with the way the DataGrid works today. Their answer was to avoid conflict and create an entirely new GridView Web control. The GridView has everything that the DataGrid should have had in version 1.1, such as a seamless paging and sorting interface, as well as an easy-to-implement method for binding to business objects (among other things). You should use the GridView control for any new development that you do, as well as consider porting your DataGrid controls to the GridView to take advantage of its more robust feature set. The DataGrid control was left in the toolbox as a temporary resolution to the legacy dilemma.
The legacy dilemma is an issue that should not be taken lightly. Ignoring it can have serious consequences. As an example, my team was tasked with re-writing a Web application for one of my clients using ASP.NET 2.0. While we were upgrading the code, we decided to give the existing user interface an upgrade, as well. We aligned all the controls, standardized font sizes and colors, streamlined the data entry process, and added an enhanced menu layout and position. The result was an incredibly polished user interface that my client absolutely hated. Although the new user interface that we created would be a clear favorite for new users of the system, we didn t account for the shock that it would create within the existing user base. They had grown comfortable with the user interface that currently existed (with all its faults). Unlike Microsoft s situation, adding a parallel data entry interface was not a valid option, so in the end, we compromised and kept the standardized fonts and colors and the new menu position, but reverted back to the old control and menu layouts. Needless to say, I gained a new appreciation for the legacy dilemma.
The legacy dilemma is difficult because sometimes big changes are really necessary to move a product forward. A perfect example is the tectonic shift from Visual Basic 6 to Visual Basic.NET. Although Microsoft enraged millions of developers by so radically changing the language that they had grown to love (despite its obvious shortcomings), the change was necessary in order to avoid the eventual extinction of the language. It simply had to fully implement the .NET architecture to remain viable. The Visual Basic team at Microsoft did endeavor to keep as much familiarity as possible, however, by keeping features like the built-in datatype conversion functions, as well as the verbose keyword methodology in its various coding constructs.
There is no absolute solution to the legacy dilemma, but the key to minimizing the problem is to thoroughly consider and study the impact of proposed changes to your products and services for their impact on the end user or customer. Determine if the change is really necessary. If it is, then consider whether a dual interface is a viable option (like the DataGrid/GridView solution). If a dual interface is not an option, then make as few changes to the existing product as absolutely possible, and provide a clear migration path for existing users via easily accessible help files. Don t remove any features unless there is no alternative. Before removing a feature, release a version that marks the feature as deprecated and gives instruction on the new way to do things. It may take several versions of your product to move your customer base to your grand vision, but you ll avoid shocking the system as much as possible. That means keeping your customers, instead of encouraging them to look at competitors products.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.