email article printer friendly

What's Under the Hood?
The escalating use of APIs, platforms, and patterns is opening the developer's art to close inspection
by William Knight

Posted April 28, 2004

My father owned a vintage Hudson Super Six. It was a 1925 saloon car with a top speed of 50 mph, it managed 6 miles to the gallon, and it stalled at every crossroad. At weekends he tinkered with the engine, cleaned the spark plugs, fixed the leaking radiator, and built his own parts. He stuck the car together with chewing gum and kept it running through his enthusiasm and tenacity.

In contrast, his modern car was never touched. It was used for work and family trips and went to the garage for servicing. Professional mechanics fixed it when it broke down, and he didn't know how to lift the hood even to check the oil. The fact that somebody else—Volvo—had made the car reliable, economical, and efficient meant that he no longer had any interest in it. Most of the problems were solved, and anything left over was too complicated without a degree in engine maintenance and a car-tuning computer. A modern car was no fun, so for his kicks he turned to the Hudson.

The software industry has reached a similar point in its evolution. Not long ago we only dreamt of standard libraries, well-known patterns, and formulaic architectures. "What if," we pondered, "this utility was reused across the company. It could save us millions." We understood intimately the code we wrote and loved to fiddle with it; making it run faster, use less memory, and rid it of the occasional stack overflow. They were exciting times.

Change was inevitable. Where a buck or competitive advantage could be made, products were created to make software development better, faster, and cheaper. The solution space was partitioned into patterns, frameworks, libraries, application servers, Web servers, and APIs, and we were pressured to become experts in them all, bowing to the impossible wishes of recruitment agents—that we have ten years experience of each.

These days it's not just the programming language that's used as a communication tool, but the pattern book, the EJB framework, plug-in components, white papers, and articles. Instead of resisting change, developers must understand the fundamental problems of design and architecture in the words of others. You might find your ability to communicate is dramatically improved.

Peer Pressure
Where we used to build projects from scratch, now everything is industry standard. Our temptations to create anew must bow down to solutions of other designers, and being a professional programmer means keeping up with your education, maintaining a library of up-to-date textbooks, following the latest design patterns, and being knowledgeable of system architectures.

The size of the task and the pace of change should not be underestimated. J2SE 1.5 has twelve core APIs and four integration APIs. There are six user-interface toolkits and two deployment technologies. The development tools—Debugger, Compiler, Javadoc, and JPDA—each require in-depth knowledge to use efficiently, and for the enterprise developer there are no less than 23 J2EE APIs, including essential mechanisms for database access, messaging, Web services, and servlets. If these were not enough, the application of each API has attracted much comment. There are white papers, case studies, code examples, and thousands of books, all increasing the pressure on developers to keep up to date since decisions and assumptions can be verified online at the click of a mouse.