The Cost of Cutting Edge

Back Draft

 

The Cost of Cutting Edge

Cutting corners in your Web applications can carry a hefty price tag.

 

By Jonathan Goodyear

 

In a previous Back Draft column entitled Recipe for Adoption, I talked about what ASP.NET needs in order to gain broad-based acceptance among corporate IT development shops. One of these factors was research-related. It's tough to justify forging into ASP.NET for large production systems when there isn't an established set of Best Practices in place. To my astonishment, I have seen an unusually large contingent of companies take the ASP.NET gamble earlier than I expected. This early adoption has done a great deal to reassure Microsoft that it is heading in the right direction. From what I have seen, however, many companies jumping into the ASP.NET pool are doing so quite recklessly.

 

This recklessness is due largely to the Microsoft marketing machine. Developers and managers have been led to believe that they can achieve tremendous performance improvements by merely selecting ASP.NET as the development platform for their Web applications. Nothing could be further from the truth. Bad design and bad code will run poorly no matter what development platform you choose - compiled or not. It takes a great deal of planning and .NET know-how to design ASP.NET Web applications that produce these advertised performance measures. ASP.NET cannot, in and of itself, carry the day.

 

The transition from the interpreted linear script language architecture of traditional ASP to the compiled object-oriented event-driven architecture of ASP.NET means you need to spend a lot more time designing your Web application than before. This means you should consider bringing in talent that knows what they are doing with .NET to help architect the system. If you try to apply a "learn-as-you-go" approach to building an ASP.NET Web application, it will fail miserably. At best, you'll end up with a hodge-podge of mixed strategies; at worst, you'll wind up with a Web application that doesn't work at all. Plus, it is often tough to tell what advice to follow because much of the abundance of ASP.NET resources both in print and online is speculation, and it takes an experienced eye to tell the difference.

 

Traditional ASP was more forgiving from a design perspective because each page was pretty much independent of every other page. In ASP.NET, your entire system is an interconnected network of objects. These objects need to be designed carefully and assigned to intuitive namespaces. Thought needs to go into issues such as caching strategies, inheritance, and Web Services. The enhancements in ASP.NET can be a great boon to your Web application if they are applied properly, but they can lead to disaster if implemented incorrectly. And because backing out of a failed approach in ASP.NET is trickier than it was in traditional ASP, mistakes can be very costly.

 

Over the past six months, I have been approached by numerous clients who attempted to "shoot first, ask questions later." These clients hired cheap labor to develop ASP.NET Web apps, and when things started going sour, they wanted me to examine their systems and identify the problems. It saddens me to see their disillusioned faces as I explain to them that their ASP.NET Web application was designed completely wrong, applies .NET concepts incorrectly, and will not stand up under production load. And now they must pay me to bail them out. Usually, this cost is much higher than if they had approached me to help them design their application in the first place. As Steve McConnell eloquently put it in his book Software Project Survival Guide (Microsoft Press), "design flaws caught downstream are much more costly to fix than those caught upstream."

 

The point I want to emphasize is that ASP.NET is an extremely powerful Web development architecture, but its features are not plug-and-play - regardless of what you've heard. You cannot design an ASP.NET Web application successfully in a haphazard manner. You must take care to ensure all aspects of the system integrate well together. There are also some interesting challenges that crop up regarding team development of ASP.NET Web applications. Your project might benefit from enlisting the help of a .NET expert to help you design your first ASP.NET Web application and help your team get up to speed with .NET development. Once you are on the right path, you can use .NET experts in a less regular "mentoring" fashion. Sure, it's going to cost extra up front, but you'll save a lot by not spinning your wheels as much.

 

This column might seem like an advertisement for consulting services, and in a way I suppose it is (though not for any consultant in particular). The bottom line is, however, that if you are forging into ASP.NET at this early stage, the adage "you can pay me now, or you can pay me later" applies. When ASP.NET has firmly established Best Practices, you can more comfortably solicit rank-and-file developers to design your Web application. But until then, get the help you need - before it's too late.

 

Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, Fla. He's 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.

 

Tell us what you think! Please send any comments about this article to [email protected]. Please include the article title and author.

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish