August 29, 2007Web 2.0/AJAX complicates, not simplifies, substantial application development and porting projectsNice article by Tom Yager how to plan your application. The key phrase here is -- ...The stages of Web application development are the same as for any n-tier software: analyze, architect, specify, design, code, test, QA, support, repeat...
Web 2.0/AJAX complicates, not simplifies, substantial application development and porting projects web2-maze_hp.jpgThere are few things more frustrating than filling out the last page of a four-page form on what purports to be a Web application, pressing Submit (or, if the site really fancies itself to be an app, Save), and getting "Server failure--try again later," a SQL error sloppily spewed out to my browser, or "You are not connected to the Internet." That last one is a problem on my end, sure, but it's the site owner's responsibility to deal with any failure condition gracefully. When I get the site back, my session has timed out for my protection, and I have to start over. That's when I know that this would-be app was designed by someone who has never written a commercial client/server application, and that realization causes me to lose all faith in whatever services this erstwhile app purports to provide. That outfit lost my business for failing to understand the huge difference between a site and an application. I wish this were an isolated occurrence, but organizations are going ape over the promise of apps that deliver the desktop experience while running entirely on a server, zero client code, completely client-agnostic. No one interviewing for a high-paying job as a Web app developer is going to point out (if they know) that unless the original application was idiot simple, turning it into a Web site is harder than many other types of porting projects. If you're hiring a developer to create a Web app, the make-or-break interview question should be, "If I told you to turn this desktop app into a Web app, what's the first thing you'd do?" I almost hate to give away the answer, but what the heck, developers willing to oversell their skills aren't savvy enough to read InfoWorld. The stages of Web application development are the same as for any n-tier software: analyze, architect, specify, design, code, test, QA, support, repeat. A Web app developer worth his salt won't go near HTML or JavaScript until the business logic, processes, states, and data structures are mapped out and interfaces are agreed to. Thought and debate must be invested in determining how things such as state information, field validation, and the storage of database query results should be split between the browser and the server. The under-the-hood stuff can then proceed along a parallel path with the user-facing elements, but the presentation is subservient to the application, which is, as always, designed solely to make its users ecstatically happy to sit on their butts all day pulling the strings that make your solution work. With Web apps, as with all development projects, everybody needs to kneel down before quality assurance, but QA takes on special responsibilities with Web applications. It's QA's job to humble proud Web developers by running the app on screens that are too small, text size dialed up to the browser's largest setting, connections that are too slow or break in the middle of a transaction, bungled or bogus e-mail addresses, server traffic and resource overloads, database changes after associated screens have already been displayed, forms filled in that can't be posted before the browser or TCP/IP stack times out, Buy Now buttons that are clicked eight times, and sessions that are allowed to idle for six hours with no activity. In other words, scenarios that a local application would never face must be tested in realistic conditions. Don't pretend you're hitting the site from a cell phone or over a dial-up session interrupted by call waiting; actually do it. Don't warn a tester that you're pulling the network cable from the wall; just do it. The response to every failure scenario has to meet not only desktop and n-tier application standards but can't-fail, server-hosted Internet software standards as well. What would Outlook and Exchange do? What would Amazon do? What would BlackBerry Enterprise Server do? These may not reflect the scale or purpose of your Web app, but you can't put the Web application ribbon on your software until it is as responsive, resilient, and reliable as native software and the best examples of commercial Web applications and sites. More often than buzzword fanatics would like to admit, all of this extra QA, which has to be revisited every time a browser changes, is more trouble than it's worth. Terminal Server, application virtualization, thin client computing, Flash, and a host of other methods meet or approach the zero-client code requirement without imposing special conditions on architects, designers, and developers. If you finally decide to take the Web app route, know that the only people qualified to create Web applications are experienced n-tier application developers. Handling the project any other way will yield a Web site that drives like an application, but fails to meet expectations that an "application look and feel" creates in users. You'd better deliver. |