THE VIEW FROM INSIDE
Starting a Web project? Be ready to keep the faith
By Walter R. Houser
One of the biggest errors agency people make is to look at Web projects through rose-colored glasses.
Make no mistake: Despite the fancy new technology, a Web application is a substantial software engineering project. The bad news is that all the familiar problems of software development apply to the Web. The good news is that your familiar and trusty tools can be used to solve them.
Gone are the days when customers were satisfied with techies simply cutting and pasting text into a simple Hypertext Markup Language page. Today they want electronic commerce, complex applications linked to robust databases and Web front ends linked to legacy applications.
Such demands stem from the fact that Web developers have become the victims of their own success. Customer expectations have gotten out of hand. The Web is the panacea, and webmasters are the magicians who seem to work miracles. The power of the Web is limited only by the imaginations of those who are willing to pay the bills. And the bills are substantial.
Few of even the most mature Web applications are paying their own way. Many programs will require parallel Web and non-Web operations for the foreseeable future.
More troubling is that government agencies find that their applications run afoul of policy and organizational cultures while pushing up costs. Even purely informational sites can grow to the point that they are unmanageable. Agency managers heap on so much that their sites resemble an electronic ransom note with sentences pasted together from headlines clipped out of magazines.
Software engineers use many approaches for managing the development process. The oldest is the waterfall model, named for the linear stages of effort that, in diagram form, resemble a waterfall. The starting point is identifying user requirements, followed by systems requirements and architecture. Next come detailed design, development, implementation and maintenance.
In an incremental variant of the waterfall model, the design, development and implementation stages are conducted component by component to keep the process and product under tight control.
In the spiral or evolutionary model, developers perform the steps twice or several times. Each iteration is done with greater detail and rigor. The waterfall model works well for small projects or for projects whose results are clearly defined. But if the requirements are big, vague or unstable, the waterfall model tends to lead to the wrong result. Feedback between customer and developer tends to be highly formal and of relatively poor quality.
Yet some developers like the waterfall method because they can intimidate a customer into agreeing to a specification that the customer barely understands. When the customer invariably complains that the product is not what was wanted, the developer points to the requirements analysis, saying, 'But you said here that's what you wanted.'
After a couple of 'gotchas,' customers get the impression that they have been taken
advantage of, and they generate little repeat or referral business for developers.
The spiral method is more challenging for developers because they have to meet with customers more frequently and must obtain their agreement several times during the process. The customers get to touch and feel the product as it is built. Consequently, they interact and synthesize new solutions.The parent trap
This moving target of customer preferences, however, can frustrate developers. Applications are like children: They are born with great potential but little definition. Gradually they develop in unexpected ways. Like parents, neither customer nor developer truly knows the results of their partnership until it is complete.
This is especially true for Web applications because the technology and the target audience change so rapidly. Also like parents, developers and customers must want their uncertain endeavors to succeed. When things go wrong, the mutual blaming often spoils what should have been a partnership. Technical and program people need each other like blades on a pair of scissors.
In starting a Web project, expect rough going but avoid the temptation to walk away from it. Faith, trust and commitment are more important than funding and technology. Walter R. Houser, who has more than two decades of experience in federal information management, is webmaster for a Cabinet agency. His own Web home page is at www.cpcug.org/user/houser.