Yet another Getting Real review

I recently finished reading Getting Real by the 37Signals gang. After which, of course, I decided to chime in with yet another review.

I enjoyed reading the book – and I agreed with most of what they said. I have, after all, been immersed in Agile for over 4 years now – and I’m also a firm believer in Interaction Design.

An example of a part I disagreed with was about it being okay if team-mates are not co-located. I don’t care how they claim to have worked it out (DHH no longer lives in Copenhagen FWIW), I think team-mates should be in the same room – if possible.

Anyway – it is a pleasant enough read, even if it simply re-iterates what many other books already say – the agile series, interaction design series, lean software, theory of constraints etc. If you want actual theory and a deeper understanding, read the full list. If you want instant gratification without the longer term benefits of understanding the concepts behind this stuff, read Getting Real.

Heck, read it anyway – its kind of a fun book.


I’ve been busy, working on two very interesting projects these past several weeks (on the side – my current project for work is unbelievably mind-numbing). Both these projects are in Ruby and use Ruby On Rails. There, got that out of the way.

I’ve always been in search of software designs that result in a clean DSL (Domain Specific Language)… lisp style, bottom up, bring the language up to the problem, rather than the other way around, etc. What I’ve managed so far is a set of mini-DSLs in my applications. One for each module, so to speak.

And perhaps, that is the way things work in general; rather than the unrealistic goal of building *one* DSL which is supposed to capture your entire domain – build several, smaller ones, which each capture aspects of the domain.

Improving team communication – Or on teams and snacks

I was having a discussion with a friend who asked what in my experience had been an effective way to improve team communication and enthusiasm in an agile project room. We discussed various ideas, but later that evening, I remembered this –

Here’s a quick and easy way to improve team communication on a local team. On one side of the room, place a table. Place a supply of snacks – candy, cakes, drinks and coffee, fruits etc. Replenish this every time levels diminish. That’s it.

People will gather around it to grab snacks and they will talk. People will talk as they eat, they’ll throw candy wrappers at each other and they’ll gel. The level of trust will go up and as people make the transition from colleagues to even friends, aided by the banter and the food, the level of noise in the room will increase somewhat (usually a good sign) and the team will become more effective.

It worked for me…!

CVS Quick Reference

I’ve looked up this information in the Open Source Development With CVS book so many times that I decided to put it up here so others who might want it can get at it just as easily as I can.

* Creating a repository: cvs -d init
* Importing a module: cvs import -m
* Checking a module out: cvs checkout
* Adding and checking files in:
o cvs add -kb
o cvs -q commit -m
* Updating a module – be in the same directory as project: cvs update -dR

More information can be got either from the cederquist manual or from the book mentioned above – its quite good, actually. Of course, you’re using subversion now, right?