Clear is better than fast; the Web services model gets it.
Steve McConnells 1993 book, "Code Complete," is one of the few software development titles that a huge fraction of programmers claim to have read. Its second edition is due in June, and impatient coders overfilled a ballroom at the Santa Clara (Calif.) Convention Center when McConnell previewed his updated thoughts at the Software Development West conference earlier this month.
McConnell understands that one of the worlds scarcest resources is programmers time. Some experts focus on squeezing the most out of hardware with complex code optimizations, but McConnell said in his talk that "50 percent of execution time happens in 3 percent of the code; if people optimize as they go, theyre likely to be wrong 97 percent of the time." Making code clear and understandable, he asserted, has much more benefit for enterprise value than making code fast.
I fully agree. Complex code is less likely to work the first time, less likely to be understood well enough for another developer to use it as a starting point and more likely to be so tightly coupled to a particular platform that it has to be rethought almost from scratch before an application can take advantage of new opportunities. Ive seen this problem on every platform from programmable calculators to supercomputers, and its usually meant that I had to write something myself instead of being able to refine (or even believe) the code that had been in use before I arrived.
Later that same day, while participating in a panel discussion on software development trends and opportunities, I heard a surprising comment that also supported (if indirectly) McConnells view. The primary panel topics were XML, SQL, Web services and grid computing. A fellow panelist, Microsoft Distinguished Engineer Jim Gray, candidly told our audience, "I couldnt make DCOM work. I tried and failed, again and again. But I can make a Web service in a heartbeat."
DCOM, Microsofts Distributed Component Object Model, grew out of the desktop-centric COM that first enabled useful tricks such as editing an Excel spreadsheet embedded in a Word document. DCOM was often and aptly described, though, as essentially "COM with a longer wire"a DCOM object exists only as long as at least one process maintains a reference to that object.
Although tolerable on a single PC, DCOMs optimism doesnt suit long-distance networks using less than perfectly reliable links, as I pointed out at least as early as 1999. And if DCOM is too complex for Jim Gray, winner of the Association for Computing Machinerys Turing Award for his work on transaction processing, then mere mortals must rejoice that theres something more approachable in the offing.
Web services follow my fundamental rule of desirable software development trends: They exploit the fact that hardware gets faster and cheaper more quickly than programmers get smarter. I include myself in that population. Given the choice, Ill propose a project in Java, LISP, Smalltalk or even BASIC, all of these being environments in which the machine mostly takes care of the machine, and I need to think only about the mission of the code.
On past occasions when Ive been paid to use a language that involves explicit coding of low-level functions, such as managing memory, I felt as if I were taking the clients money under almost false pretenseslike a taxi driver who keeps the meter running while stopping to wash the car and put gas in the tank. The client is paying but is not getting any closer to the desired destination.
And even in the current environment of offshore competition, programmer time remains a scarce resource. As McConnell observed during his keynote, "The tech bubble and the Y2K issueboth huge itemswent away within a few months of each other, and we still have no more than 5 to 15 percent unemployment in our field." Thats a lot if youre part of that percentage, but its not much in terms of the growth rate of demand for new functions that call for new code.
All the more reason for developers to maximize their contribution by adopting and mastering tools that help them in every possible way.
Technology Editor Peter Coffee can be reached at firstname.lastname@example.org.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.