I'm not quite certain what I think about Spring Roo, and I'm not sure whether it will become a mainstream java development tool, but I have to say it is damned interesting. It's taken two rounds of playing with it, separated by months, and seeing Rod Johnson demo it last month, but I have a better idea of what it is.

The Roo site says that "Spring Roo is a next-generation rapid application development tool for Java developers. With Roo you can easily build full Java applications in minutes". Rod Johnson described it as an effort to come up with a way to make Java programming less cumbersome, to prevent the JVM from become a legacy platform swept away by the newer generation of platforms like Ruby on Rails. So it is trying to achieve a similar goal to Grails, but in a dramatically different way.

I'll take a stab at explaining what Roo is. It *could* be described as a round-tripping code generation tool. That is, you tell it what you want your domain model to be, and Roo generates the application code, including all of the scaffolding. The round-tripping part means that it's not a one-way thing. You can edit and extend the code Roo generates, and Roo can still maintain the scaffolding, and even add scaffolding as you add, modify, and remove elements of your domain model.

So the phrase "code generation" sells Roo insultingly short. It doesn't just generate code, it manages the scaffolding code dynamically as you work with your code.

What scaffolding does Roo manage? At the class level, it manages things like getters, setters, toString(), and the like. So you write your class file, add the fields, and the other bits are added behind the scenes. These are actually generated and managed in separate Aspect files. You can open and even edit these files, but editing them will break Roo's model. But no worries, if you want to override the code that Roo generates, you can do so in your own class file. Override the setter, and you're in charge. Annotations in your class file enable and disable Roo management, and often let you configure what Roo does. If you really need to change the way Roo handles some aspect of your classes, you can write a Roo plugin.

The upshot is that , but your class files are refreshingly clean, only containing the logic that really counts, and you're still you're pretty firmly in control of what happens.

At a higher level of scaffolding, Roo manages persistence and the interface, including the presentation layer and web services. Again, you have a high degree of control. You can specify which persistence framework you want to use - Hibernate, TopLink, etc. - and pretty much any database you're likely to use.

The tradeoff for this is an interesting thing. The main price is that your application pretty much needs to follow the architecture and certain key design patterns that Roo uses. For example, persistence uses the Active Record pattern, with methods added to your domain classes, rather than DAO with separate DAO classes. You can disable this and write your own DAO's, but the Roo folks make a good case for accepting that DAO's are counter-productive with Roo applications.

In fact, the basic premise of Roo is that it will create applications using best practice patterns, and the latest mainstream Spring frameworks (Spring MVC, Webflow, Spring Security, etc.), and make it easy to keep your application up to date.

A corollary to this is that, unlike Grails, say, a Roo application is a "real" Java application, one that in theory you could have written without Roo, at least if you are the type of hyper-anal developer who makes a separate aspect file for the toString() method for each class.

Roo is not a tool for "dummies" who want to whip up an application without having to understand how Java, and the frameworks involved in creating a modern-day J2EE application, work. It can help an inexperienced developer create a simplistic application very quickly, but my guess is that a developer without a solid understanding of what's happening under the hood will get stuck - or unstuck - pretty quickly.

It could be a helpful learning tool, or a crutch that prevents a developer from properly learning. For example I haven't work worked with Tiles, but now I have a working Tiles application. I can hack around with the templates to customize my application, which might result in an application whose presentation is, well, hacky; or it might boost me up the Tiles learning curve. I suppose it really depends on me.

If Roo is not a tool for dummies, what it is is a tool for experienced Java and Spring developers to save time managing the scaffolding that we've come to take for granted in a J2EE application.

Roo is not a mature tool yet, but it is amazingly well engineered. It has pretty good basic documentation, including tutorials, which are enough to get going, and fairly good coverage of what it does. The reference section for the Roo commands is a bit thin, it doesn't really give you enough of an idea of what each command is for, and why you might want to choose particular options.

Although some areas of Roo are pretty thoroughly implemented - the selection of databases, for example - others have limited options, such as implementing web services, or a plugin architecture for your own application. Roo itself does have a plugin architecture, so it seems likely that if it gains traction, it will gain much broader support for different types of applications.

But what there is of Roo is impressively solid stuff. The Roo shell's content sensitive help and hint system is useful, and the way Roo dynamically handles changes you make within your code is pretty sweet. It's just a slickly done tool that works the way you'd want it to.

The biggest barrier for adoption of Roo may be that it's pretty much only for green field applications, or else applications which can be re-factored to follow the Roo application architecture. Again, the architecture of a Roo application needs to fit the Roo way, or you'll probably end up fighting the tool, and a lot of team will probably resist this. But it has real potential to become a staple tool for Spring application developers.

Spent the day at the SpringSource S2G forum, basically a one-day conference by Spring Source. It was a good experience for me - a good fit for things that I've got going on or am thinking about these days - and helped clarify for me what the SpringSource guys are trying to do with the proliferation of products I've complained about in the past.

In short, Spring's focus is on improving developer productivity, and to enable portability of applications. The appeal of the original Spring Framework was that it was much simpler and more productive than EJB, and Spring's architecture is designed from the ground up to let you plug in alternative implementations, whether it's the various bits of the presentation layer, persistence layer, transactions, web services, you name it. Roo and Grails are two different approaches, with different use cases, to bring the kind of productivity improvements seen in Rails and similar newcomers to the development platform scene to the Java platform.

STS is really the centrepiece of Spring's efforts to improve developer productivity, both by providing a pre-packaged set of Eclipse plugins to work with Spring applications, and also as a way to tie together the various parts of the Spring portfolio, such as Grails and Roo, and the various operations-side pieces like TC Server, Hyperic, and even the cloud platforms Spring is working on. The presenters at S2G all used STS, which was an effective way of showing how to get the best out of it and the specific technologies being demonstrated.

Rod Johnson's keynote was heavily focused on the cloud, in the wake of the recent announcement of VMforce and discussion of their cloud strategy. Johnson explained how cloud fits into Spring's strategic focus, which goes back to improving developer productivity, and portability of applications. It really does make sense for Spring to make a push into the cloud, since otherwise the Java platform will be left in the dust by Azure in the enterprise space.

The cloud, and PaaS in particular, is about making life easier for developers, and I know that I am certainly in the market for a way to move my J2EE applications into the cloud. At present, the only real option is to roll your own PaaS on top of an IaaS like EC2, which is a lot of work.

So Spring Source's Cloud Foundry, VMforce, and the other offerings that seem to be in the pipeline will really hit the spot. And they do more than just offering an Azure equivalent, but true to the Spring philosophy, they give us alternatives, whether it's different services to host on, or even the option to deploy a PaaS in our own data centre. So we'll have portability, even the capability to deploy our applications across multiple cloud providers simultaneously. I'm sure that the market for helping enterprises create private clouds will be big, even if it's not "pure" Cloud.

There were a number of other points Johnson made about Cloud that really hit the mark with me. I'm definitely keeping an eye on this space.

I've been disappointed to see otherwise switched-on technical groups, and even high-priced 'managed hosting' companies, fail to take advantage of virtualization, even as they spend (and charge) loads of money to migrate physical servers onto virtualized infrastructures such as VMWare.

Moving from an OS running directly on hardware to an OS running on software that pretends to be hardware opens amazing possibilities, akin to the shift from paper to online data management. You're replacing immutable, physical servers with data, which means you can treat your infrastructure the same way you treat any other data - you can automate it, copy it, transfer it, and basically put it at the mercy of anything you can script.

While it's disappointing to see people use virtualization to replicate the experience of hosting on immutable, physical hardware, it's truly appalling to see hosting vendors offer this as a service, and add a premium price on top. It's only more annoying when they call it 'Cloud'.

I've recently seen a tender response from a big name, international hosting provider which basically offers to provide you with a couple of dedicated hardware boxes with ESX installed on them. Reasonable, if not ideal; obviously it's more powerful to have access to a pool of hardware resources that you share with other customers, so you can flex capacity when you need to, but there are reasons why a customer might not want to go this way.

What blew my mind was the way virtual machines on these boxes would be provided. For each VM, you pay a setup fee, and a monthly management fee. These fees are in pretty much the same ballpark as what you would pay for dedicated hardware for each of these VM's. But this company also charges a very hefty fee for each physical ESX box, so you're actually paying quite a bit more for N virtual machines than you would pay for N physical servers.

On top of this, you lose the flexibility that virtualization allows. Need to spin up a new image to prototype some changes to your application configuration? Request a price, get an invoice, raise a PO, pay a setup fee, and commit to three months of paying for the new image. Need to clone a running image to debug a production bug? Similar story. Expand capacity for a few weeks to support a marketing campaign? Implement an upgrade strategy that involves cloning, upgrading, testing, then swapping the clone into production? Even after you've jumped through the budgeting and purchasing hoops, you'll need to send your 'managed' hosting vendor a change request and wait a few days for their engineers to use the virtualization management console for you to carry out each step.

I'm not a Capability Maturity Model kind of guy, but I could see the benefit of having one for virtualization, to help enterprise CIO types understand what they should be demanding from vendors. The lowest level would involve using virtualization to replicate physical hardware, and the next would introduce flexibility in managing instances, supporting the types of use cases I described above. Higher levels of maturity would be more cloud-like, particularly around self service in provisioning images, flexible capacity management, and dynamic provisioning. I see higher levels of capability moving away from Infrastructure as a Service and towards providing a development and deployment platform that abstracts the details of servers, i.e. Platform as a Service.

A virtualization CMM would be grossly abused by marketers, but something like it might provide a few clues, and stomp out the practice of hosting providers offering virtualization without the benefits.

Chris Wong responded to the reactions of several dzone commenters to my post on Spring's weightiness.

Chris takes up the question that several commenters raised on dzone, i.e. how do we define 'lightweight' when considering whether Spring still is. He digs back to Rod Johnson's original mission statement for Spring, and concludes that Spring still does meet those criteria.

I think he's right. What I was whining about in my post was really not that Spring, as a framework, is no longer a lightweight platform. It is, and is still my starting point when building an app of more than trivial size.

My moaning was really about the ecosystem of enterprise solutions that Spring Source has built up around the framework. Trying to figure out what these various things actually are is a pain. There is a lot of useful stuff there, but it requires a pretty heavy investment, in both time and cash, to work out what it all is, which parts may be useful to my organization, and how to fit them into our architecture.

On the plus side, it's all still open source at it's core, so once we do work out what's what, we have plenty of choice about how to use it. If our needs are more complex, and our budget larger, it's worth looking at splashing out for the enterprisey, supported versions that Spring Source offers. Having played with Roo, and investigated Spring Integration and other web services pieces, it's clear they're still a pragmatic, dare I say it, lightweight alternative to the stuff put out by the likes of IBM, HP, and Oracle, and one that's still acceptable to pointy-haired bosses.

What's truly key is that if our technical strategy favours the use of lighter, open source components, the Spring folks are still putting out stuff that meets our needs. Hopefully they won't lose sight of that.

I received an email from my boss with a link to that Spolsky piece on duct tape programmers which had previously got my blood up. The boss obviously doesn't read my blog, but he's been around the block enough that he didn't take Spolsky's piece at face value.

Nevertheless, when Martin Fowler's recent post on technical debt came through my reader, I shot the link back to my boss.

Reckless debt may not be inadvertent. A team may know about good design practices, even be capable of practicing them, but decide to go "quick and dirty" because they think they can't afford the time required to write clean code. I agree with Uncle Bob that this is usually a reckless debt, because people underestimate where the DesignPayoffLine is. The whole point of good design and clean code is to make you go faster - if it didn't people like Uncle Bob, Kent Beck, and Ward Cunningham wouldn't be spending time talking about it.

Duct tape design topic (not Fowler's term, he doesn't refer to Spolsky's post at all) is only a quarter of the quadrant in Fowler's post, the whole post is worth reading.

The inverse to the technical debt metaphor is the investment metaphor, i.e. investing time to build a solid architecture, or refactor, or whatever. This metaphor is widely used, as it's a natural one. Of course, it potentially runs counter to the YAGNI principle. Interestingly, Martin Fowler is not an uncritical advocate of YAGNI, he expresses his ambivalence in his Is Design Dead piece.

I think it would be worth drawing up a quadrant for YAGNI v. BDUF similar to the one for technical debt. I'm not sure what the axes would be. One would probably be the level of knowledge confidence you have.

"Knowledge confidence" refers to how well you understand your requirements and the technologies and patterns you will use to address them, and the confidence you have that these will not change. In other words, are you sure whether you're gonna need it, or could it end up being de-scoped to hit a delivery date? What's the cost of putting in a simpler solution that won't necessarily address every requirement, then refactoring it as you reach that requirement in the backlog? How does it compare to the cost of developing a more complex solution up front that supports requirements you never get to, meaning there are requirements in between that get left out as well because you spent time on the complexity you didn't need?

Joel Spolsky's recent piece on Duct Tape Programmers takes a characteristically extreme position that programmers who get stuff done simply and quickly are wonderful. I say characteristically extreme, because Spolsky has a columnist's approach to writing, i.e. take an extreme position that will get people worked up, although (actually because) it has obvious holes to pick.

I like to say that programmers fall on a Engineer / Hacker Continuum, and that each end has both positive and negative examples. On the engineering end, you have people who like to thoroughly think through what they are doing. The negative version of the engineer is the over-engineering architecture astronaut. They make everything harder than it needs to be. Their first reaction to any change request is that it's probably impossible, and in any case will be difficult and expensive, needing major parts of the system to be refactored, frameworks ripped out, etc.

On the opposite end of the spectrum is the Hacker. Managers love the hacker, because their first reaction to anything is that it'll be easy, and by the time the managers finish discussing whether to do it, the Hacker has already knocked it up. This is Joel's Duct Tape Programmer.

The evil side of the Hacker is that many (not all) of this type of programmer get things done quickly because they don't bother to think everything through, much less test it (Joel's dream programmer thinks unit tests are a luxury). They've coded it up, the code compiles, and they can click through the happy path on their development machine. Ship it! Oh, wait, I forgot to commit my code to the repository. Done, ship it!

Of course this results in bugs, customer complaints, and general disaster, at least if the company has any real customers. It works great for startups, because it gives them something to demo ("we have a working application"), and nobody is using it so the bugs don't matter.

So the positive flipside of the Engineer is that they take care, think things through, and design and build solid applications.

I've worked with Hackers who develop solid, clean, simple code, They're wonderful, they get stuff done quick. I've also worked with Engineers who keep their designs simple and effective. Also wonderful. But more often I've worked with developers who will slide into the negative versions of these if left to their own devices.

A development manager who follows Spolsky's principle of worshipping the Duct Tape Programmer, thinking they're always going to get the positive version of the Hacker work (code that's developed quickly, **and** is solid, fast, and scalable because it's been written simply and cleanly), are eventually going to end up tearing their hair out, not understanding why nobody can get the app to stop crashing, why new features take forever to develop even for their golden Hackers because nobody can untangle the spaghetti (in reality the Hackers end up writing new apps, because it's faster, which creates a new kind of spaghetti).

The Spring Framework emerged as the lightweight alternative to EJB for Java developers. It was simple, sensible, and had low overhead for designing, developing, and running applications. Over time it has grown from the platform of choice of subversive, technically-driven teams who want to get things done effectively, into the platform of choice for Enterprise Java development teams.

This is great, the best technology has won. But now Spring has become a serious company, and acquired by a bigger company which itself is majority owned by a massive company. And on the way, it's become something which smells to me like an Enterprise Solution.

I'm not talking about the corporate structure - I've got no problem with that in itself. And I'm not talking about the core framework itself, or even the family of extra components that have been acquired. I'm trying to get my head around the development suites, the application servers, the other application servers, (and now I see they even have a web server?).

Now, I have great respect for the guys who developed a lightweight Java platform that the pointy haired boss will sign off on using for corporate projects. If they are similarly packaging quality, useful open source software like Eclipse, Tomcat, and OSGi server, and so on, so that it makes life easier for designing, developing, and running well-engineered applications based on the principles of simplicity, then rock on, let me at it.

But I can't make heads or tails of the Spring Source suite of solution offerings. I have a look at the pricing, and I can't see the practical difference between these and offerings from IBM and the rest. What I do see is going down this road makes my cloud strategy awkward. I can't dynamically add and remove server images in response to useage requirements if I have to count the CPU's and pay a thousands of bucks every time I do so (waiting for the purchase to be approved by corporate each time). So it's not very lightweight from that perspective.

And I can't even work out what each Spring Source product does and whether it makes sense for me to even consider spending the cash, I quickly get bogged down by solution-speak every time I try to get a quick understanding. Then I saw a notice about Discovery Days, and hey! a day-long seminar which goes over the various Spring Source solution offerings and explains what the hell they are, sounds perfect. Oh, wait, it costs £400. They want me to pay to go to their sales presentation.

Bleh.

I gave Google's Chrome web browser another go, and after a bit less than a week I've gone back to FireFox. There are two reasons for this.

First, although Chrome might be faster when using Google's online apps, more stable since each tab is a separate process, etc., from a user experience point of view there is simply nothing compelling enough to make me _need_ to keep using Chrome. It isn't ten times better than the alternatives in any aspect of its use that I really notice on a regular basis. Firefox doesn't crash very often on me.

The second reason is plugins. Firefox has loads of plugins, which in effect means it has loads more functionality than is available in Chrome. In practice, there are probably only two or three plugins that I truly rely on. The first time I tried Chrome, shortly after it's release, I used it at work, and not for very long, because of FireFox's built in functionality for password management, and the password timeout plugin to enhance it. I use a lot of passwords when browsing at work, for the various online tools, test deployments of software, etc. I can't remember them all, but I don't want to just let Chrome remember them, and make them available to anyone who gains accesses to my PC. So I use a master password, and a timeout plugin that makes sure the master password is required fairly frequently.

This time around I used Chrome at home, and it turns out I don't rely on FireFox plugins quite as much in that context. However, last night I was surfing and ended up delving into a thread of links that seemed quite interesting for work, and wanted to save them to Delicious. I'm used to using a FireFox plugin for this, and realized I'm incapable of living without it. That was the end of Chrome for me, for this round anyway.

Chrome will probably add a plugin API, but we'll see whether it helps it become more than a me-too in the browser market. Firefox has won a 22% share of the market by doing compelling things that IE didn't do at first, and didn't do well when they finally added them (tabbed browsing and plugins). Chrome's intended killer features seem to be that it runs complex online apps faster and more stably. Unfortunately for Chrome, FireFox is not currently slow or crashy enough to make this a clear win for most users, but perhaps as the online applications become increasingly complex it will matter.

Here are some blogs I'm currently following about Lean proceses. Some are focused on software development, some cover lean processes more broadly.

These are blogs focused on Agile software development as well as Lean:

These are pulled dynamiclly from my Google Reader account, so will change whenever I change my subcriptions.