In recent years, I’ve been called on to write a lot of low-level system software, like parsers, compilers, high-availability data stream monitors and the like. But at fairly regular intervals, I get the opportunity to lead teams of developers in enterprise projects using J2EE.
It’s an interesting sensation to contemplate the architectural choices made by developers of bleeding edge frameworks and tools. We’ve come a very long way. The Enterprise space has been whipped by high winds of innovation, driven by big players like IBM, JBoss and VMware, the makers of Spring.
I’ve found these frameworks to be both fascinating and frustrating. It doesn’t happen often, but sometimes you strike a brilliantly conceived tool that is sadly, poorly executed, and consequently unusable in production. Sure, we often have the source code, but busy team leads and developers are sometimes not in a position to select tools that don’t work on first download.
In the Open Source space, I’ve got into the habit of reading the sub-text of a project, trying to determine how long I can expect a particular tool to be supported. Sourceforge is the repository of some truly great projects, but it is also the place where brilliant OSS projects go to die. It is exciting and fearsome at once to contemplate having to integrate a new application development suite into a mission critical project. The first time something is used in anger is always a gamble, and careers are often on the line.
Three weeks ago, I started a very exciting new project, the details of which are unimportant at the moment. Suffice to say it was a J2EE application, and on the face of it, we had a lot of hard slog to get through in development. Not unusually, time was critical, so naturally, our thoughts turn to Agile and RAD. What tools did we have available to take the drudgery out of all of those endless Beans that would eventually need to be written?
Of course, Spring is high on the list of frameworks for consideration, which meant it was time to have a fresh look at Spring Roo.
Spring Roo is an application generator for Java. It uses a very sparse scripting language that allows you to specify high-level intentions, describing the major architectural aspects of your application. When I say “sparse” and “high level” I am not exagerating. Here is a command to reverse engineer an entire database and produce the EJBs and Aspects needed to access it in JPA;
database reverse engineer --schema reserve_planning --enableViews --testAutomatically --package ~.domain
That’s pretty much it, bar a few details about specifying connection properties. When you execute that, if your database and data model are solid, you will get a complete set of enterprise java beans and application-ready methods set out in a perfect application structure, ready to deploy. Not bad. Not bad at all.
Behind the scenes of course, what goes on is fantastically complex. Using convention over code, a standard application should always be able to be generated out of a standard database structure. This is the theory, and in most instances, it works. We’ll come to what happens when it doesn’t work in a moment, but suffice to say, this is a very good thing.
It’s good, because it removes the drudgery from coding, while at the same time massively improving the quality of the software produced. The application so generated is excellent, and the fact that it happens in seconds instead of days is revolutionary, even though we have been using code generators for more than thirty years.
Tools improve, and we are finally to the point where code-generators are able to transcend their technical limitations. As we get better and better at getting machines to do those mindless tasks we detest, we are free to do what we do best, which is conceive and create. I have written before about the dangers of runaway automation, but this is a case where humanity is well-served.
Have I written my last EJB yet? Has Roo relieved me of the need to do hands-on coding? No, sadly, we are not quite at that stage. Another couple of years and a few dozen add-ons down the road and perhaps I will be able to let go of that, just as I have been able to let go of MASM, and Assembler programming, and inspecting the instructions generated by my C compiler. One day soon, I may never even need to think about EJBs again.
We’ve been here before of course – RAD research began in earnest in the late 1980’s. I was involved in serious commercial efforts to use Rapid Application Development in a large enterprise, attempting to go beyond the CASE Tools of the day. The earliest efforts at going beyond code generation to convention, visualisation and automation were technical successes, but few made it to market. CASE, or Computer Aided Software Engineering was a methodology for generating code based on database schemas. It worked brilliantly, but it was not fully “round-trip”, unless you were prepared to accept all of the constraints the tools imposed.
Round-trip engineering mean going from the high-level abstraction, to code, and back to abstraction. Changes in either are reflected in the other. Roo now does round-trip development, making use of its annotations by monitoring changes to code under maintenance.
But still, there is a gap. We are not at the stage yet where development no longer requires hands-on programmers with detailed knowledge of J2EE and core Java.
In the recent project I mentioned, I found the Roo environment and workflow are still not as forgiving as one would hope – deviating from the path laid out in the cookbook examples can result in many false starts with no real explanation forthcoming from the tool. I needed to use MySQL, not the in-memory H2 instance of the examples. There were all of the usual teething problems. It took an all-nighter for me to find and fix all of the Maven dependency gotchyas, the version incompatibilities, the unfixed framework bugs and so on.
Fair enough, that’s the job, and really, if I’m honest with myself, I enjoyed it – I enjoyed using Roo, and I enjoyed cracking all of the heinous maturity issues that sometimes challenge us and keep it interesting.
However, in the same way, I also enjoyed being an Assembler programmer, and I enjoyed the esoteria of C. While it was fun at times, it was wearing. Eventually, it was all too hard, relative to the pleasure of coding with Java when it came along. With Java, I could simply express myself without having to worry about cleaning up after doing a malloc, and other petty distractions. Using Roo, I could feel another one of those historic transitions coming on, even as I fought with it to make it do precisely and only what I wanted it to do.
In the washup, all that Roo fundamentally lacks is the ability to diagnose and correct its own errors. This would go a long way to closing the loop, so that applications could be created almost entirely by models, conventions and intentions. Seriously, if we must start using computers to write code (which is what code generation really is) then why can’t computers debug code as well?
How would that work? The error messages of the compiler and the server are mere grist for the mill to a rules engine. We can do a lot to improve the tools we have with error trapping and expert diagnostic systems which would allow code under management to be automatically refactored, or to recommend solutions to developers where this is not practical. Once we can do that, the entire process chain of development could then be realigned to remove the burden of application programming from humans.
We can do this. Roo Wizards similar to what exists in the proprietary version of MyEclipse are another move in the right direction. As are the visual front ends that are so familiar to JBoss users. Roo is almost there.
“Closing the Loop” would mean defect-free software would become the norm, not the exception, and that’s a strategic goal of all senior developers. Just as it is no longer necessary or even advisable for me to specify the linkages of my own binary objects in a separate Linker in order to write a Windows application, I shouldn’t need to be involved in the creation and management of what amounts to standardised code elements and low-level components in Enterprise applications.
In a year’s time, I fully expect Roo to be a formidable weapon in the war against drudgery and unforced defects, especially if it begins to seriously close the loop.
This is an example of good automation, automation that elevates and enhances the role of human creativity, by relegating the drudgery to computers. This is the kind of of man-machine interface we see in the alternative Rodenberrian Universe of the future, where computers are unobtrusive “actuators” of human intention – “biceps”, not “brains”. If you are not familiar with this design philosophy, spend a happy couple of hours watching any episode of Star Trek, and pay close attention to the use people make of computers. Computers facilitate and actuate human intention without interfering or imposing or being “too helpful”. This allows human intelligence, personality and creativity to come to the fore.
Contemplating these aspect of design and architecture pays big dividends with respect to software quality. When computers do the thinking for humans, humans quickly stop thinking. When computers exalt and enhance the creativity of humans, human creativity is liberated, and becomes boundless. This fine line is actually not so fine on closer inspection – it delineates a growing chasm between opposing schools of computer system design.
Architects, Designers, Developers and Managers all need to be aware of tools like Roo, and the implications they have for the future and the way we work. Large teams of programmers may well be a thing of the past, so programmers should decide now, what career path they will pursue – specialising in the high-level, or going deep, developing the underlying code that enable next-generation tools like Roo to perform. In any event, our work practices will need to change, as design becomes even more important, and as the quality of data models and workflow processes become the primary determinants of application success or failure.