In War and Peace Tolstoy remarks that military science assumes that bigger armies with more men wield greater force.
On the other hand, only vaguely, do they recognize that during military combat the final strength of an army is also its true physical capacity multiplied by one unknown variable.
One unknown variable. This variable is none other that the spirit of the troops measured as their greater or lesser desire to fight and confront danger.
Men with the desire to fight who also understand why they are fighting regardless of who they are fighting whether under military geniuses or those of normal intelligence fighting with clubs or machine guns that fire 30 rounds a minute these men will put themselves in the best positions and so they will win.

Immediately after hearing this I’ve started a comparison with agile projects.

It’s obvious in these days, with agile becoming mainstream that bigger armies (expensive tools? costly hardware? costly solutions?) and bigger teams don’t imply success in software development.

What is then the unknown variable in an agile team?
I would compare the physical capacity with the knowledge base of the team, with the general collective intellect.
The desire of fighting is nothing else than desire of success and play with risks and issues in a project.
But then, it’s in the understanding of the why they are fighting the most interesting part.

I’ve seen teams over-performing in few different situations: some were strongly committed to the success of a startup, feeling part of it (my experience at Fluidtime), some other were committed to reach excellence (a common behavior at ThoughtWorks).

The why can be different from team member to team member, some people need to feel that they are part of a whole, some others need recognition and differentiation.
Some others are carrier driven, some others have a strong desire to learn, improve.

Finding the right motivation in your team members will make your team run faster and smoothy, the unknown variable will boost your speed and quality.

Complexity

Writing software it is still way to complex in these days.
I can recall few attempts to make it easier, they all failed: Java Enterprise & EJBs, Web Services, Enterprise Service Bus.
Rather than making things simple they forced you to write more code, to use lots of xml, tons of libraries, implementing unnecessary interfaces.
How many days do you waste every time you start a project, just in infrastructure & build files?

REST seems so simple, but implementing REST in the right way seems always so damn complicated, so everybody writes RESTish services, a good progress compared to old style web services but still…

What about web applications?
I like the simplicity that can be achieved with Sinatra, Scala , WebLocks and Seaside.
But still, the impression is that nobody is trying hard enough to make all these things even simpler.

The Twitter example

I’ve started using Twitter only few months ago (even if I’ve the account since 2006…), it started to make sense when I’ve linked it to my Facebook account. Facebook is like software in these days: way too complex.
Too much stuff, too much noise, too difficult to get what you really want.
Then I’ve started to use TwitterFeed as well, I’ve my flickr, google reader and tripit profiles feeding the twitter account.
So we have three content providers, one content consumer and forwarder and one content receiver, it’s a fairly complex architecture and it never failed so far, it’s quite stable, it just works.
I didn’t had to write a line of code, I’ve pressed just few links, it all works using RSS in a RESTish way.

Simplicity

How do you imagine software development in ten years?
I do imagine it like in the twitter example, an aggregation and collaboration of few simple services working together.

The role of the Agile movement

Agile is treating the symptoms, it’s true, I’ve seen many times agilists (including me) preaching for the old good principles (don’t reinvent the weel, keep it simple, etc) but how many times do we have to rewrite the same software?
For how long will we have to rewrite the same objects, the same business logic?

Why are we still writing web applications like ten years ago? Why are we still using Spring, Hibernate, Databases, Layered Architectures?

I think it’s time for laziness, simplicity and more real reuse, somebody told me that it’s an utopia, but even only trying will make the IT world a better place to be.

Agile can cure the disease

The Agile developer community, being so open minded and always embracing chance has a great chance to change the way software is written.

There’s not so much new from a process point of view in these days (at least, that’s a complaint that I’ve heard from many people, especially coming back from big Agile gigs), but there’s so much work to do on the technical side of things.

The NoSQL movement is one of the signs that something new is just born and growing, don’t miss the opportunity.

The wall will be handled like a retrospective one, clustering common subjects and people will be asked to vote, then I’ll choose the most interesting and I’ll talk about it .

This will give me a chance to understand how and where agile software development is going in Italy and it will be quite a challenge: I won’t bring my Mac, I won’t prepare anything, pure improvisation!

Surely I’ll blog about it right after, and hopefully I’ll find some time & energies answering to some of the unanswered questions on the blog.

With this experience report I want to share the experience of a continuous, repeatable successful project: the agile cocktail we created worked perfectly for us. This is not necessarily saying it will be perfect for you. However, on any future project I will always begin with this mix, inspecting and adapting it afterwards, only changing if necessary.