All entries for Thursday 01 May 2008
May 01, 2008
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