What’s in your wallet?

Yesterday my wallet was stolen during a ThoughtWorks away day, thus marring an otherwise excellent day. I’m filled with impotent rage, but also racking my brains trying to remember what was in my wallet. Which little used credit cards might I have forgotten from my slew of late night card cancelling phone calls?

Do you know exactly what’s in your wallet right now? One thing’s for sure, when the white hot fury cools enough for me to start acting rationally again, I’m buying much smaller wallet that will force me to only keep a couple of cards in it.

Inversion of Control for teams

On the majority of software teams a hierarchy exists. There’s a pyramid of developers, senior developers, tech. leads, architects, project managers etc. The architects design the system and tell the tech. leads what to do, and the tech leads go to their teams and tell them what to do. The most experienced people are at the top of the pyramid (ie. furthest from the coal face), and there is a natural progression down until you get to where the code is being cut by the most junior members of the team. Hmm.

A self-directing, agile, emergent team doesn’t fit this model. When roles are fluid, and more like hats than job titles, a more service-oriented organisational style tends to emerge. The pyramid becomes partially inverted. In a well integrated and happy agile team the developers become the customers of the architects and tech. leads. As issues or design difficulties emerge, the developers seek out the guidance of the tech. leads and architects. The senior technical team members continue to remain responsible for the overall design themes and patterns within the system, but in a more event-driven, iterative way instead of an up-front, top-down imposition of designs that may not fit the reality the developers are working with.

Why a 20 minute build is 18 minutes too long

I’ve just started working on a project team with a healthy obsession with build times. It had crept up to 20 minutes before some cunning hackery by Simon and Carlos brought it down to 7. This includes running the signed off acceptance tests and the database. The trick is to keep everything in process. IO is the enemy. But that’s a story for another day.

The point is, why is a fast build so important? It was Mike that said it best: having a screamingly fast build doesn’t make it easier to do the same things, it makes it possible to do entirely new things. When a build takes less time than a trip to the water cooler, you can build (and check in) every time you go to the water cooler. Doing a build becomes part of the rhythm of developing. Test, code, refactor, build, check-in. Repeat.

Code Reading

I enjoy reading code. In many ways it’s like reading a mystery novel. Or one of those ‘now turn to page 67’ roleplaying books. Actually very like reading one of those roleplaying books. For those who have no idea what I’m on about, there is a genre of book, usually of the sci-fi or fantasy ilk that puts the reader in the role of the main character and allows you to make choices about what happens next. Like an Infogrames text adventure in paper form. So you’d read a page that describes a situation then be presented with a sentence like, ‘You stand at the door to the brooding castle. A path leads around to the rear of the castle. To open the door and enter the castle, turn to page 34. To see where the path leads, turn to page 68.’ And so it goes. But I digress.

Reading code is an adventure of a similar sort. Every polymorphic call or conditional branch is a choice that must be made by the reader. Do I step into the ‘if’ block, or find out where ‘else’ goes? Which of the 4 implementations of ‘isValid’ do I want to look at first? Slowly, after much backtracking and re-reading, a mental map of the system begins to form. I also like to take offline backups to index cards while I’m reading, due to a somewhat limited personal heap size.

Code reading is a learned skill, just as reading in general is. You get better with practice. As with literature, there is much more bad writing than good writing. As with literature, the ability to tell good writing from bad improves the more you read, as indeed does writing skill.

We should all read more code.