Like many others around the country, I spent the recent bank holiday weekend attempting a spot of DIY. And as I knelt on Monday afternoon, cradling the still-warm corpse of yet another terminally mis-jigsawed section of wooden flooring, I calmed my sobs and began to consider how I could turn around my DIY failures.
In my head, I took chalk to the still-unpainted wall and drew a scrum board. Post-it notes fluttered across; user stories popped into my head: “A visitor wishes to walk across the floor without spraining her ankle …”
Of course, I didn’t do this. I didn’t need a sophisticated engineering methodology – I just needed to be much better at DIY.
Step away from the power tools
Back at work, I’m a much better software engineer than I am a carpenter. That’s not saying a lot, but I have a dozen years of experience under my belt, and I’ve poured some of my best work into our products. And there’s plenty of room for improvement.
Developing our implementation of Scrum and Agile matters not a jot if our programming skills slide. One way the two might work well together is code reviews. We’ve talked about implementing a team-wide formal code review system, but never actually tried it. And unlike many of our recent innovations, I have been far from enthusiastic about attempting it.
A great idea
Why? After all, on paper, it’s a great idea. There’s a bunch of tools available to make it easy – we can put our code up for review by the whole team, who can add comments and spot any potential problems. The less experienced can learn from the more; while the more experienced can spot opportunities for improvement in our own code as well as each others’.
Our progress in other aspects can be reviewed, too. As we try to clean up and refactor our code, we can consider best practices amongst the team, and look for more opportunities to simplify and improve our code base. As time goes on, we’ll leave behind a trail of improved code, as well as developing important skills now and for the future.
As I say, on paper, it looks great. So why have I been so reluctant to try it?
Back to the floor
Let’s go back to my new flooring. I know I’m no great DIYer, but I put a lot of sweat, tears and blood into my hallway (the stains will come out with time). It’s mostly flat, runs almost parallel with the skirting boards, and hardly creaks at all. I’m proud of it, and when someone comes to visit, I want them to say, “Gosh, what an excellent new floor! You can hardly see the hammer dents!”. The last thing I want is a professional builder to come round and snigger at the edging.
And with the code I write, more so. I should be writing perfect code all the time – I certainly shouldn’t be introducing bugs, smelly hacks, or unnecessary complexity. My ego can just about handle the fact that my flooring is on public view, but it would prefer, at work, to be pouring its output, safe from prying eyes, into a thick, black, sealed box containing only my code.
And there’s the key point – my code. A key facet of agile development – indeed, any good software development environment – is that the code is not my code, it is our code. At a simplistic level, the company owns all my output, but more importantly, what I produce is something that we as a team have committed to.
Communal code ownership, and its sister, horizontal feature assignment, are things we have been striving to achieve in our Agile aspirations. It remains, however, difficult to assign ownership of my code – perfections as well as flaws – to the team. And yet, if I want to get the most out of code reviews, be they formal or informal, it’s one power tool I’ll just have to learn to master.