May 01, 2008

The SpringSource Application Platform: why would I want it?

In my experience, software development projects can be divided into two worlds: those that can be done with a small team, and those that need a big team.

By “small team”, I mean about 4 people, and certainly no more than 6. Basically, if you need more than 2 pizzas to feed the team, it’s not small. Big teams, on the other hand, are typically more than 10. That’s because there’s an interesting phenomenon which happens on teams between about 6-10 people, which is that suddenly the effort to communicate between everyone in the team becomes much larger, so much so that adding more people actually makes things worse, until you get above about 10. Then you can start to form a normal hierarchy (2 sub-teams and a co-ordinating team) and get going again.*

Small teams, I have found, are much more productive per person. Before I came to Warwick I was involved in a 100-person development team (40 java coders, 20 business analysts/testers, 20 assorted managers and 20 admins/testers/other hangers-on) which eventually collapsed under it’s own inefficiency after 18 months. The best 6 people were pulled from the wreckage, and re-implemented the entire project in 6 months flat. This is not unusual. Sure, there are lots of projects that are simply too big for a 6-person team to pull off, but every year the range of stuff that can be accomplished by a small, focussed team, gets larger and larger.

There’s a marked difference in the kinds of tools and frameworks that suit ‘small-team’ development and ‘big-team’. Small-team frameworks focus on enabling you to do as much as possible, as quick as possible. The poster-child for a small-team framework is surely Rails, but of course there are many others.
Big-team software is focussed on preventing other people from screwing up your stuff. In a big-team project, individual productivity isn’t that important compared to effective modularisation and decoupling, because you can always just add more programmers to go faster. J2EE is (or at least, was) the ne plus ultra of big-team frameworks, although with JEE5 (and even moreso with 6) it’s making it’s way back towards the little guys.

It’s a bit like the difference between vertical-scaling software (buy the fastest single server you can) and horizontal-scaling (make it possible to run your software on lots of servers)

Now, I have a personal preference for small-team development. Slightly unusually, I also have a preference for java – small teams frequently prefer dynamically typed languages, as they fit closer with the ‘sacrifice safety for speed’ philosophy. The single biggest factor that’s enabled me to square this circle has been the Spring Framework – a set of libraries that give me the ability to get a simple web-based project up and running in next to no time, but knowing that whatever I’m going to need in the future, be it asynchronous message processing, WS-* remoting, distributed cacheing, flexible declarative security,or whatever, it will be available, and it will fit in with everything else.

So, I have to say that I was a teeny bit disappointed when I read about the new SpringSource Application Platform. An application server which is based on OSGi rather than EJB for it’s modularisation.
Now, I don’t doubt for a moment that OSGi is a much better technology than EJB for modularisation. Lots of folk are using it, for humungously complex projects like eclipse, and it works really well.

What irks me, though, is this: why would I want OSGi modules? I’m quite happy with 1 great big WAR file, thanks. Neither I, nor my happy few developers, need the ability to break our app up into little bits, version them and then dynamically lazy-load them. In fact, I think lazy-loading a web app is a terrible idea, and I can do all the modularisation I need to with ivy at build time.

Of course, this is just sour grapes. Big-team developers do want this, and SpringSource have every right to give it to them. It’s just that I’d got kinda used to Spring spending time and effort on what I want, not what those enterprisey guys in suits were after.

Spring started out it’s life as a reaction against the excess baggage that J2EE development entailed. By their own admission, SpringSource have put a lot of time and effort into this product, and doubtless they will need to keep on doing so – and AFAICS that’s time and effort that’s not being spent on making ‘lightweight java’ easier. SpringSource, you have become what you beheld; are you content that you have done right?

* Astute readers will point out that the ‘web development’ team that I run has 12 people in; but in terms of product development it really runs as 3 or 4 2-3 person dev teams, plus a 3-4 person ops/support team (with some overlap, maths fans). We only function as a team of 12 when we need to take over a corner of the pub

- 3 comments by 1 or more people Not publicly viewable

  1. anon c.

    I’ve been asking myself the same question: Why would I need this?

    I thought I was quite happy with 1 great big WAR file (in which case S2AP is not for you). But then I remembered when I was new to J2EE, and set out to develop my first web app. I had learned all about modularization at university, and wanted to put it into practice – which turned out to be impossible.

    So step back, and think about what would be possible with plugin-based web apps. It’s certainly a fantastic opportunity for product development (think Confluence, even though they do have their own custom plugin mechanism). From what I’ve learned so far, S2AP looks like it could become a server side Eclipse RCP. If you’re happy with 1 big Swing app, there’s no need for Eclipse RCP. If you want modularization and extensibility, then Eclipse RCP (or NetBeans RCP, or whatever) is for you.

    02 May 2008, 10:39

  2. Chris May

    Modularisation is good; there’s no debating that. But I’m not sure why I would want runtime modularisation, rather than build time (which I can do perfectly well already). I can see how, if I were making a product which was designed to be deployed by lots of different people, in all sorts of configurations, then runtime/deploy-time module customisation a la OSGi is great (and Confluence is a perfect use case for this) – but most of my apps exist only in one configuration (albeit on lots of servers) – so I’m not sure what a plugin architecture would get me, over and above the level of modularity that I’ve got right now.

    02 May 2008, 14:25

  3. Rod Johnson


    We’ve very content we’ve done right. We are growing rapidly. We can simultaneously deliver this product and push Spring forward vigorously. That’s not just my assertion: it’s demonstrable fact. Look at the Spring releases in recent months: Spring Framework 2.5, Spring Security 2.0, Spring Web Services 1.5, Spring Batch, Spring Web Flow 2.0 on its way… I can’t think of any other company in enterprise Java that’s currently producing quality open source software at that rate, or any other set of projects that is moving so fast.

    If you don’t need the SpringSource Application Platform that’s fine. Keep using what you do need. But every company needs to cater to different groups of consumers. For example, I love my car. The manufacturer that makes it also makes excellent motorbike. I don’t want to buy a motorbike. But if they make money out of motorbikes that’s great, and I believe that people who are into motorbikes love their product.

    But I would encourage you to learn more about OSGi. In my experience, the “big fat WAR” model is flawed, especially when you start sharing applications. But if your situation is different, that’s cool. Run Spring on whatever you run it now…

    Many people didn’t see the need for Spring when it first appeared. We believe the enterprise story we’ve built on top of OSGi will be a similar story. But even if we’re wrong, you won’t be any worse off :-)


    02 May 2008, 17:42

Add a comment

You are not allowed to comment on this entry as it has restricted commenting permissions.

Most recent entries


Search this blog

on twitter...


    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI