Many, many years ago, I wrote my first computer program as a student at Georgia Tech. It was a simple program to implement a math function, written in Algol and punched into cards. I knew the algorithm to implement the function, but I spent a good amount of time just trying to get the computer to do what I wanted. Much of my effort grappled with control language requirements, file I/O operations, printer output and the like.
As I worked on some recent programs in ILE RPG and Java, I had a flashback to the Algol days. Most of my time was consumed in dealing with programming issues, rather than defining the application. Although the IDEs I have available now give me an unquestionable boost in coding speed over keypunch machines or antiquated editors, the requirements for “plumbing” and interface code have grown so much greater since the Algol days that at times I think the expanded volume of code cancels out the productivity gains from IDEs.
Granted, contemporary applications have a lot more bells and whistles, look prettier, and can be accessed anywhere in the world via the Internet. But why hasn’t the way we build applications improved as much as the applications themselves? Why haven’t we reached a point where applications aren’t just richer, they’re also easier to create and adapt?
Ajax provides a great example. Let’s be honest, Ajax is a kludge and far more cumbersome to use than should be necessary for what it delivers. Ditto support for persistent application objects, which require either a lot of explicit I/O coding or mastering baroque technology like Enterprise Java Beans. At this point some sharp readers may feel like pointing to the next cool, open-source platform or framework that’s going to make things so much easier. But in my experience over recent years, I don’t see a strong trend towards simplification of business application development. Instead, I see a constant succession of “better ideas” for how to make the computer do cleverer tricks, without moving application development to a higher plane.
I think the problem arises from the interaction of several forces. First, a rigorous, yet practical, approach to application software development isn’t widely taught in either vocational schools or colleges. Our education system produces lots of academic computer scientists and artisan programmers, but few application software engineers.
For reasons I can’t fully explain, the IT market has also failed to produce any environment for model-driven development that has a substantial market share (or “mind share”), comparable say with the extent the market has adopted several new languages and supporting libraries over the last decade or so--e.g., Java, PHP, .NET. Why is it that much of the development community would pick up a language like Java, which originated with a single vendor, and yet the same success has never happened with any vendor’s higher-order application development environment?
Of course, there have been, and still are, successful products of this sort, known variously over the years as “CASE tools,” “application generators,” “4GLs,” and so on. But most developers are still mucking around in the code. When you take a cold look at how we write software, can you honestly say that PHP isn’t just the RPG of its day and will end up being seen as just as primitive in due time?
If there were several of these higher-order products with substantial market share, the competition among them and the wider revenue base would surely advance the state of development at this level much more rapidly than has happened. Again, look at how much has happened with Java and .NET at the level at which they attack applications, all due to their respective market shares.
And, if there were several of these higher-order products with substantial followings, educational institutions would have a basis for teaching “application software engineers” both concrete principles and real-world practices comparable to what one finds being taught in other established engineering disciplines.
The third major factor is the lack of accurate and comparative cost assessment for application software development. Outside IT, few enterprise managers have even a clue at how to assign the full life-cycle costs to software development. Inside most IT organizations, where we might expect a more quantitative approach, there seems to be an aversion to the time, effort, and pain of dealing with accurate software cost accounting. This makes the short-run costs of “hacking” seem the better choice over serious, long-term investments in skills and tooling. To be fair, it’s also hard for IT managers to know in which development technologies they should invest in, since there aren’t any solutions that have market share on the same order as Java, PHP, .NET, et cetera.
After my “flashback” to Algol, I pondered how in the past several decades there’s been no major shift in approaches to application development since high-level languages, such as COBOL, supplanted machine languages. True, there have been some refinements, such as object-oriented languages and aspect programming. But none of the changes have been transformational.
So, in keeping with the times, here’s my proposal: Allocate a few billion dollars from the stimulus package and fund two major IT initiatives:
And for the side of the political spectrum that favors tax breaks over funding new programs, let’s legislate a “klunker software” program that gives a credit to businesses that transform their legacy applications (using the new tools, of course) to a more productive development foundation, and let’s give additional educational tax credits to developers who complete accredited programs in application software engineering.
If technology is going to be the key to a revitalized economy, energy independence, health care reform, and global warming, then let’s get serious about finding better ways to develop the software that all these efforts will depend on.
Paul Conte is a System iNEWS senior technical editor.