I received an excellent link from Jon Mulholland, pointing to Getting Real, a book published by Chicago-based web development company 37signals. Interesting company this is (thank God they did not call themselves 42signals, think we all got that message by now). They strive to create ‘the best web-based software products possible with the least number of features necessary’ and also they are proud to announce that their products ‘do less than the competition ‘.

Quite a big thing, simplification.

And no doubt one of the most difficult qualities to create. Especially in Information Technology, where we are easily overwhelmed by all the features, triggers, widgets, gadgets and information flows that we potentially could include in our solutions. And they are tempting too, all these bells and whistles, especially if we did not really take the time to contemplate what the solution really needs. So we turn to eye candy to satisfy our short-term reflexes and soon we find ourselves absorbed in nitty gritty details and challenges that just don’t make any difference.

These guys from 37signals, they certainly drink their own champagne.  Browse around a bit at their website and you start to get the picture of what they mean with simple. And furthermore, read the book. If you want it, you can get it delivered as a good old-fashioned paperback and go through it start to finish. And I although I know you don’t mind spending quality time at all, some of you may be happy to hear that the book consists of small chapters. Indeed a great airplane book (their words, not mine…).

Alternatively, you can read the book online for free. This gives me the opportunity to be back on some crucial subjects in the forthcoming weeks. Build less. Ignore Details Early On. Race to Running Software. Rinse and Repeat:  just a few examples of the principles in Getting Real that are interesting in the context of Slow IT. If only because many of them seem to contradict with the slow approach.

This will be a crucial question that I will try to address together with you in future blog-items: in the era of Web 2.0 we are seeing more and more software that is available at a very early stage of development, never seems to be finished, and always continues to evolve. There is some overrated heroism in the idea of the perpetual beta.  But is it really a sign of rushed sloppiness, the inability to commit to agreed results and an alibi for not thinking before you start? Or is it the only way to really understand the requirements of the business and produce systems that are more robust and better tested? Or could both be true?

Let’s try to find out. Follow this blog.

In the meantime, I would like to point you to one specific chapter in the book that contains an important slow message. In ‘Alone Time’ the authors argue that interrupts are the natural enemy of effective work. It resonates with my own, earlier experiences as a software engineer: I could produce huge piles of quality code, as long as I could work uninterrupted for a longer period of time. As soon as I was sitting at the office and people would walk in and out, asking questions, starting discussions, even bringing coffee, my productivity went down the drain. Eventually I preferred to work early in the morning or – much better for me – late in the evening.

Interesting enough, this is probably why open source software is often produced so effectively : typically the team consists of members that don’t share the same location or time zone. The team may be distributed across the world and only use the Internet to communicate and synchronise results.  There is an unexpected advantage to that: the team members will have a lot of alone time, much more than they would have when working at the same offices.

And in many cases indeed, some decent alone time is all you need to create real progress.

Of course, if you are at the same offices, you can still agree to be complete incommunicado – for example between 10 AM and 2 PM. No coffee rounds, no meetings, no phone calls, no emails, no mobile phones.

Because somewhere, sometime, somebody needs to do the work.