The Legacy Dilemma

Back Draft

The Legacy Dilemma

By Jonathan Goodyear

If you examine the sugar dish on the table at yourfavorite restaurant, you ll likely see a plethora of different colored packets.Along with the traditional white packets of pure sugar there are pink packetsof Sweet n Low, blue packets of Equal, and now yellowpackets of Splenda. Even though the pink, blue, and yellow packets do prettymuch the same thing (provide a non-sugar sweetener for beverages), restaurantsnonetheless carry all of them. The reason is this: As these various productswere introduced to market, they each gained a particular market share. Theircustomers have grown to depend on a particular brand of sweetener and therestaurant owner doesn t want to alienate any of its customers by not offeringtheir preferred condiment even though one of the others would do the job justas well (if not better). Restaurants must deal with the legacy dilemma ofhaving to support and offer older products and product features for the sake ofcustomer comfort and satisfaction.

The ASP.NET team was confronted with the legacy dilemmawhen they contemplated how to deal with enhancements to the Web control toolboxin ASP.NET 2.0. For instance, one of the most widely used Web controls inASP.NET 1.0 and 1.1 is the DataGrid. It is also the most customized Webcontrol. Perhaps a hundred or more articles have been published in establishedprint media, as well as hundreds more online, teaching developers how to hackthe 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 wantedthe grid control in version 2.0 to integrate seamlessly with the new dataprovider model (using the various DataSource controls). However, it was alsoimportant to minimize the migration impact on developers who were comfortablewith the way the DataGrid works today. Their answer was to avoid conflict andcreate an entirely new GridView Web control. The GridView has everything thatthe DataGrid should have had in version 1.1, such as a seamless paging andsorting interface, as well as an easy-to-implement method for binding tobusiness objects (among other things). You should use the GridView control forany new development that you do, as well as consider porting your DataGridcontrols to the GridView to take advantage of its more robust feature set. TheDataGrid control was left in the toolbox as a temporary resolution to thelegacy dilemma.

The legacy dilemma is an issue that should not be takenlightly. Ignoring it can have serious consequences. As an example, my team wastasked with re-writing a Web application for one of my clients using ASP.NET2.0. While we were upgrading the code, we decided to give the existing userinterface an upgrade, as well. We aligned all the controls, standardized fontsizes and colors, streamlined the data entry process, and added an enhancedmenu layout and position. The result was an incredibly polished user interfacethat my client absolutely hated. Although the new user interface that wecreated would be a clear favorite for new users of the system, we didn taccount for the shock that it would create within the existing user base. Theyhad grown comfortable with the user interface that currently existed (with allits faults). Unlike Microsoft s situation, adding a parallel data entryinterface was not a valid option, so in the end, we compromised and kept thestandardized fonts and colors and the new menu position, but reverted back tothe old control and menu layouts. Needless to say, I gained a new appreciationfor the legacy dilemma.

The legacy dilemma is difficult because sometimes bigchanges are really necessary to move a product forward. A perfect example isthe tectonic shift from Visual Basic 6 to Visual Basic.NET. Although Microsoftenraged millions of developers by so radically changing the language that theyhad grown to love (despite its obvious shortcomings), the change was necessaryin order to avoid the eventual extinction of the language. It simply had tofully implement the .NET architecture to remain viable. The Visual Basic teamat Microsoft did endeavor to keep as much familiarity as possible, however, bykeeping features like the built-in datatype conversion functions, as well asthe verbose keyword methodology in its various coding constructs.

There is no absolute solution to the legacy dilemma, butthe key to minimizing the problem is to thoroughly consider and study theimpact of proposed changes to your products and services for their impact onthe end user or customer. Determine if the change is really necessary. If itis, then consider whether a dual interface is a viable option (like theDataGrid/GridView solution). If a dual interface is not an option, then make asfew changes to the existing product as absolutely possible, and provide a clearmigration path for existing users via easily accessible help files. Don tremove any features unless there is no alternative. Before removing a feature,release a version that marks the feature as deprecated and gives instruction onthe new way to do things. It may take several versions of your product to moveyour customer base to your grand vision, but you ll avoid shocking the systemas much as possible. That means keeping your customers, instead of encouragingthem to look at competitors products.

Jonathan Goodyear is presidentof ASPSoft (http://www.aspsoft.com), anInternet consulting firm based in Orlando, FL. Jonathan is Microsoft RegionalDirector for Florida, a Microsoft Certified Solution Developer (MCSD), andauthor of DebuggingASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mailhim at mailto:[email protected] or throughhis angryCoder eZine at http://www.angryCoder.com.