Agile and engineering

I shall be delivering a talk on Agile software projects on Thursday in London. As usual, I will present the common-sense rules of agile, starting with It is impossible to have specification that covers every detail of the application you are building.

If you have such specification, it contains all information that will be contained in the source code you will be writing. Therefore it should be possible to generate working software from such specification. The fact that you can’t do that suggests that the specification does not contain as much information as there is in the source code.

To deal with this, agile tells us essentially to evolve our understanding of the project together with the technical implementation. To allow us to observe this evolution, we need to work in short iterations so that we don’t accumulate mistakes and so that we can actually make the necessary improvements!

Whenever I present this maxim, some members in the audience start to feel uneasy. They say that, “my programmers tell me that I need to give them complete specification, otherwise they cannot design the system properly”, “my technical teams insist on spending weeks on complete analysis before writing code”.

I used to be in the same camp. I too though that I need to consider every possible detail (knowing all too well that the “devil is in the detail”). Yet, despite all my efforts, I still wasn’t able to unearth all dangers during the analysis. Even worse, a lot of the work I used to put in the analysis I discarded later on. Such waste!


As I improved my already impressive technical skills (I used to be arrogant when I was younger, now I’m prefect!), I realised that the answer is excellent engineering.

You see, with good design, the most appropriate frameworks, libraries and runtimes, it is possible to design software that removes the accidental complexity, leaving me to focus on the essence of what it is that I’m building. This in turn means that it is as easy as possible to make changes to the software I am building. In other words, I can allow the project to evolve, which inevitably involves changing the software.

And this is the core of the matter. It is crucial to expertly select the platform, languages; to design the components of your application as best as you can so that you never have to say. “Oh. We can’t implement that: we’d have to rewrite everything we’ve already written.”

Java, Scala, Clojure, Erlang, Haskell, …

I am interested in all these languages and most of my team regularly write code in most of them. I am very tempted to give analysis of the relative merits of each language… but I will not!

Cloud computing, virtualisation

Similarly, I am tempted to show all the virtualisation and cloud platforms we’ve got our hands dirty with. Even show the Haskell runtime and Happstack framework we’ve added to CloudFoundry. But again, this is for another post.

What can we build?

Anything you want! Very well–except, when I look for someone to deliver a project for me, I don’t do a Google Shopping search for everything, order by price ascending. I look for things like mobile transactions & accounting software, allowing bring-your-own devices to work while maintaining security, fail-safe and resilient online systems.

So, over time, I will write Cake Solution’s version of in-flight magazine. (I might even throw in something about XML–no, wait, JSON!) In all seriousness, I will work with Guy and Ian; we will find interesting social as well as business challenges and outline a possible technical solution.

If you are a business, you will learn about what is making the headlines; about the challenges and ideas you might be facing. If you are a techie, we will do our best to suggest the most appropriate approach to implementing those wild socio-business beasts.

This entry was posted in Jan's Blog and tagged , , , , . Bookmark the permalink.

Leave a Reply