ications development when client/ser
ver computing hit the scene. If your backlog is less than three years, chances are management just stopped approving anything that takes too long.
That's why RAD-style (rapid application development) fat client applications have been all the rage, though they're not always the answer. Custom logic on the server has been mostly confined to a controllable number of database triggers and stored procedures.
Anything more complex usually gets done by packaged applications, today's equivalent of the minicomputer application. There are now millions of users of client/server packaged applications such as Oracle Financials, PeopleSoft HRMS human-resources software, Lotus Notes, and SAP's R/3 business applications running on Windows NT, OS/2, or Unix on LAN servers. Yet these don't fit every business need. If there's one lesson from the business reengineering craze, it's "fit the technology to the business need."
The problem still remains: How do you design, build, test, and maintain
good server applications in a timely fashion if you're not a software company with hundreds of highly skilled C programmers (or their equivalent)? Two technologies are changing the power equation: the Web and components. The Web settles the issue of client interface. Components and scripting, for the first time, bring high-productivity programming to the 80 percent of server code that doesn't need highly tuned, compiled C code. Even better, you can build components yourself using higher-level languages.
We have been learning this lesson at BYTE as we build our own intranet. We've built newsgroup-style internal discussion groups that let our geographically dispersed editors work collectively. Dissatisfied with the first generation of Internet calendaring software, we've assembled a simple but effective group calendar. As we look at our work flow and data gathering (in some ways we're just an assembly line, with an output of a unit per month), we've opted for a combination of packaged software and homegr
own Webware. In many cases, we've accomplished a lot with a pleasantly small development effort (for greater detail, follow Jon Udell's Web Project each issue).
That's because we're leveraging what's already been done in Internet and Web technology, as well as a good deal of client/server technology. This style of development is not about learning one tool and using it for everything. What's important about our tools is that they use only a few key technologies: HTML, NNTP, SMTP, components, scripting, TCP/IP. An analogous list for early 1990s client/server computing might be C, 4GLs, database, and NetWare. The lists are complementary: Don't forget everything you know, only what never worked anyway.
More than any development philosophy to date, componentized Web-server applications lend themselves to modular design and deployment. They even lend themselves to modular learning. No need to hole up for six weeks studying an arcane methodology. Do something useful, learn from it, improve it, add to it
, scale it up.
Eventually, faster hardware will remove the performance issues behind componentized server programming. For now, you can still be a hero. Automate a time-consuming task. Automate several, and you've got a whole process licked.
Mark Schlack, Editor in Chief,
mschlack@bix.com
Serve Yourself
