This is my first blog entry for Artima. I'm elated! I figure there's little more appropriate for an initial blog entry than to reflect about the bright and cheery outlook for the past! The potential for advances in maintenance is staggering.

There's nothing quite like greenfield development. It's beautiful. It's bliss. The requirements are yours; you're not burdened by the transgressions (atrocities!) of the past. Have you ever seen an empty bug queue? You can compile and test the entire thing in less than a second. The best part has to be the potential. "Tabula rasa", "carte blanche", etc. Unlimited potential. Such development is called "green field" development. It's fresh. It all invokes images of produce, to me. When you capitalize on potential, when you achieve, it's rewarding. Soothing. It evokes reactions from the core of your brain. Stimulus. You get a sense of accomplishment, of moving forward. It's also fast: creating is – to the uninvolved – much easier to do than updating. You've heard the many brilliant bullet points to this effect. People write faster than they read and learn. Learning code is said to be 1/3 as fast as writing it, which is why it becomes demoralizing to work on maintenance changes for too long. This is also why people tend to just scrap projects, "let's rewrite it!"

Then there's the type of development most of us work on at some point or another - changes, or maintenance. Maintenance is the least fun. It doesn't carry with it the sense of creation that new development does. There are 3 major types of change in software development: additions, deletions, and updates. Realistically, you rarely see deletions in software. People don't usually remove features. It's not a very good survival strategy. Additions (new features on an old system) and updates (refactoring of existing code) are the norm. In what ratio you get to work on either depends on where you work, your lifestyle, etc.

Our brains are averse to it. Part of this is the barrier to entry (perceived or otherwise) for successful change. The other part of this is that – generally – computer science has evolved to better development efforts. We've not had a history long enough to cherish or preserve in any significant way. New development's far outstripped the maintenance applications at the beginning of every era in computing. When mainframes hit, people built new mainframe applications. When desktops hit people built new desktop applications. When the web hit, people built new HTML pages and storefronts. When Ajax hit, people built Ajax applications.

The trend is turning in on itself, where we're developing new things so quickly that the maintenance phase is being encroached upon ever quicker. Applications are ever earlier entering the maintenance phase, and there's no new revolutionary era in sight. Further, because of the connected nature of the web, integration is becoming more and more important, and change is being visited upon “pristine” applications as a matter of course.

Change and maintenance are not easy, however. We haven't enabled it to be.

We've advanced the process of building new applications. Visual Basic and the drag-and-drool revolution heralded the most recent wave of utterly unmaintainable, quick, application development. Ruby On Rails will script you a fully working application in 10 minutes. It's perfect. Just deploy! Unless... you need to integrate. In which case, tack on 10 months to that project. Java got popular because it enabled middle-of-the-road development on new applications and facilitated a the new network programming paradigm. Not because it was more useful, or because it had the speed advantage, or because there were more libraries for it.

There are some branches that have started gearing towards change, for example the Agile movement. The methodologies by which software is built more and more embrace change. That's a step. There are tools that are designed to facilitate change, like SOAP. But this process isn't easy. It still feels like a kludge. No one uses SOAP because they want to use SOAP. People use SOAP because it unifies environments. If you could control the universe though, I imagine you'd much rather all applications that you build or integrate with speak the same tongue. That way, they would all benefit from some high performance, native remoting protocol specific to your platform. No regrets. It's not a “natural” choice. It's the best, given the circumstances.

It's time for a big change. Java, for better or for worse, is entering its maintenance lifetime. We've squeezed a lot of development inertia for greenfield projects. The next step is building out and standardizing the integrations, the changes. SpringSource- the company behind the Spring Framework - is doing a lot of this. Spring Batch is a framework, and the necessary infrastructure, specifically for batch processing – an age-old black-art that is in need of standardization. Spring Integration is an API geared toward tieing disparate data and services together. Because ESBs, and Spring Integration, model these solutions in a high level configuration format, they're made easier. Because they're easy, they're approachable. The patterns - and knowledge - behind ESBs are definitely there. Higher level tools like Business Process management (BPM) are providing business with the ability to reuse and composite process, human, automated, or otherwise. BPM makes such reuse elegant, which makes it simple, which makes it quick.

There's lots of room for improvement, though. I see plenty of support for running sexy new Ruby On Rails apps in the .NET and Java environments. Where's the support for running COBOL and C? JNA's definitely a good first step, but hardly the same thing. In the JEE world, JCA components are probably the hardest part to deal with because they are necessarily vacuous and open-ended. More infrastructure to augment that part of the process would do wonders for big corporations. Vendors like BEA make a killing with middleware like Tuxedo whose sole job is to provide reuse of legacy services. Surely the market's there?

What thing will make maintenance and reuse easier? What's the next big old thing?

Resources

1. The mind of the programmer
2. Joel Spolsky, "Ten Things You Should Never Do".