Octo’s White Paper on Java Productivity

There’s a nicely written white paper on java productivity called “Java Productivity Primer – Twelve guidelines to boost your productivity with a software factory” (great name too). It’s written by consultants working at Octo (Guillaume “Groovy” Laforge’s former employer, think of it as the French ThoughtWorks… ).

While some of it can sound as pretty obvious (use it to convince your peers or management if that’s the case), I do like how they explain the reason for TDD, what development factories bring (even for smaller teams), why managing the build process from day one is a good idea, how it suggests Hudson as the continuous integration server, why you should use a source repository even for teams of one, among other things.

But there are a few things I don’t quite agree with.

I’m just no longer buying the Tomcat + frameworks (Spring, Hibernate, …) as a lightweight solution pitch. I mean, how lightweight can a solution be when you deploy 80% or more of the runtime with your application? The last thing a small development team wants to do is manage those software dependencies and deployments. Get a Java EE 5 app server and be done with those concerns. To be fair to the authors, this is a common perception in the industry.

Presenting REST as the only mentioned way to do Web Services just because it builds “on the web” is just way too simple. SOAP is here to stay and has a place. Others have covered this (+ this is a rat hole).

Finally, maybe somewhat of a nitpick but SVN is no one size fits all. While a much better CVS, one should also look at distributed systems (such as hg). Offline commit anyone?

Oh, and I still can’t decide if Maven is a blessing or a curse…..

Download the white paper from Octo’s web site.

Author: alexismp

Google Developer Relations in Paris.

2 thoughts on “Octo’s White Paper on Java Productivity”

  1. In Octo’s white paper we read about Spring: it’s not very surprising and common in past years. But also of spring security, spring mvc and groovy/grails which are more surprising. Perhaps there is a bias towards Groovy from one of the author ?
    But when I see today that SpringSource acquires G2One (Groovy and grails) it is not a bias in Octo’s white paper it seems to be a (pay)check.

  2. Hi Alexis,
    The choices we made were highly contextual, considering we’ve been building them at our clients’ office.
    We arbitary choose to go by default on Tomcat + Frameworks to have the architecture (layers, aspects, etc.) under team control’s perimeter ; say : inside the code. It helped us when facing learning curve concerns (for random skilled guys), corporate release processes adaptation, and finally, unit testing concerns. About how to easy unit test each concern (persistence, business logic, user/app dialogs, specific UI behaviour, etc.) with an app server, I must say we found poor references and practices on the java communities and inside the teams themselves.
    Now, i must admit our focus is more on the approach and the fact that productivity is a real concern for a team so they should talk about it.
    On the specific tech choices, they will evolve, they have to. Your point is right : 80% of server’s job is inside the code and doing the same thing in all applications seems weird. However, i’m balanced because i don’t know exactly if i can get a team unit test easily on an app server, starting tomorrow. If you have something to match both, i’m all ears.

Comments are closed.