eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The eWEEK Excellence Awards for 2004 are now accepting entries. Developer productivity is critical to achieving next years IT goals, and developer acceptance is vital to the success of any IT platform, so I hope to see developer tools well represented in the field of entries that well be judging as the new year begins. The deadline for submitting entries is Jan. 31, 2005; for more information, go to www.excellenceawardsonline.com.
Development tools have a long tradition of pushing PC hardware more aggressively than any other software genre—and machines get faster more quickly than people get smarter, which is why we may never end our continuing upward spiral of higher-level tools for writing code. Software factories, notably the Jetson tool set released last week by DataSource, of Greenbelt, Md., represent the coming years run around that axis.
Jetson attacks the complexity of developing Java 2 Enterprise Edition applications using Enterprise JavaBeans, an excellent but undeniably complex component architecture. “EJBs represent the most difficult part of J2EE development, but they provide the level of services that enterprises need,” said DataSource President/CEO Pamela Hopkins when we spoke prior to the products release.
I distinctly remember the first time that I walked through an EJB-based design and realized that it felt very much like doing quantum physics with Feynman diagrams. (Ironically, theres now a software tool for drawing those diagrams: No matter how easy things get, theres always someone willing to work harder to make them easier still for everyone else.)
Developers using Microsoft Access or Visual Basic might find that Jetson makes their lives much easier: “Access/VB developers using the beta product with no documentation were able to build an application that met scalability needs and the desire to move to an EJB/SOA approach,” asserted DataSource CTO Joe Brinkman during the pre-launch conversation mentioned above.
Jetson isnt the only contender for the future mind share of rank-and-file enterprise developers. Microsoft wants to move those Visual Basic troops forward toward its own enterprise-application development offerings with factory-development tools in the next generation of Visual Studio. Microsoft development gurus like Ward Cunningham and Jack Greenfield (whos just co-authored a new book on software factories) are trying to avoid the academic introspection that sometimes seems to afflict software development progress.
“You get into the theory and you wind up with pattern experts writing patterns for other pattern experts,” said Cunningham during a conversation we had late last month. “We back them up with implementation patterns,” he said, adding, “What I see in .Net is not only a coherent set of classes and frameworks, but their assembly with a purpose in mind.”
The coherence that Cunningham mentions should not be taken lightly. No small part of Windows mind share comes from the way that the platform and tools work together. Personally, I tend to resist using anyone elses monolithic design, preferring to have the freedom to mix and match my own choices of best-of-breed boxes and connections: I like what I hear when DataSources Hopkins says that “One of the goals is to generate code that you can take anywhere else so that you dont feel forever married to one tool.” Thats not the same, though, as being able to move without cost between J2EE and .Net.
Some will say that boundaries between platforms are the price of writing really good code, whether by hand or with the aid of a factory tool or other framework. In the long run, Im not convinced of that. I distinctly recall when people warned that writing in C for processor-level portability required a serious compromise in code performance. We seem to be living with that.
This is why I call programming automation a spiral, and not a simple trend, because we seem to go through an almost identical cycle with every major advance. We grow tired of high cost, low output, and low quality at the level of tool that were using. We look at the next generation of application development and delivery, and were overwhelmed by the complexity of trying to tackle it with current tools.
We look at the greener grass on the research side of the fence, and think about bringing some of that great stuff over to the mainstream production-code side. We hear people tell us that real-world code cant live with the overheads of the inefficient code thats produced by automated tools, and that lower-level coding techniques will always produce more compelling commercial software products.
A few years later, we realize that the controversy seems to have come and gone, that the formerly speculative idea has now become the mainstream, and that were getting ready to start a remarkably similar debate over the next level of advancement and the next upward spiral spin.
Tell me what youd consider a useful move to a higher level at peter_coffee@ziffdavis.com