Thinking well is wise; planning well, wiser; doing well, wisest and best of all.
– Persian Proverb
I run. Every week. It's my waistline, you see. Perhaps it's a
guilt thing, but I do feel I need to do something to keep it under
control.
Now,
let's be clear: I'm no masochist. Exercise is not
my favourite thing in the world. Far from it. It definitely ranks
above hot pokers being stuck in my eyes. Marginally. But there are
plenty of things I'd rather do with my evenings. Many of them involve
sitting down, preferably with a glass of wine.
But
I know that I should
run. It's good for me.
Is that fact alone enough to ensure I go regularly, every week,
for the full distance? With no slacking or slowing of the pace?
It is not.
I dislike exercise and would gladly employ the weakest of excuses
to get out of a run. “Oh no, my running shorts have a loose
thread.” “Oh no, I have a runny nose.” “Oh no, I'm a bit
tired.” “Oh no, my leg has fallen off."
(Ok,
some excuses are
better
than others.)
What unseen force coaxes me to continue running regularly when
guilt alone can't drag me out the door? What magical power leads me
on where willpower fails?
Accountability.
I run with a friend. That person knows when I'm slacking, and
encourages me out of the house even when I don't fancy it. They turn
up at the door, as we'd arranged before my lethargy set in. I perform
the same kind of service back. I’ve lost count of the times that I
wouldn't have run, or would have given up half-way round had I not
had someone there, watching me and running alongside me.
And, as a by-product we enjoy the run more for the company and
shared experience.
Sometimes
we both
don't feel like going on the run. Even if we admit it to each other,
we won't let the other person off the hook. We encourage each other
to push through the pain. And, once we've run, we're always glad we
did it, even if it didn't feel like a great idea at the time.
Stretch the metaphor
Some metaphors are tenuous literary devices, written to entertain,
or for use as contrived segues. Some are so oblique as to be
distracting, or form such a bad parallel as to be downright
misleading.
However, I believe this picture of accountability is directly
relevant to the quality of our code.
For all the good it does technical writers, speakers, and code
prophets like myself to talk about producing good, well-crafted code,
and as much as the luminaries like Uncle Bob Martin extol the
(genuine) virtues of “clean” code, and Fowler explains why we
need well-factored code, it matters not one jot if, in the heat of
the workplace, we can't put it into practice. If the harsh realities
of the codeface cause us to shed our development morals and resort to
hacking at code like uninformed idiots, what have we achieved?
We can complain about the poor state of our codebases, but who can
we look at to blame?
We need to bake into our development regimen ways to avoid the
temptation for shortcuts, bodges and quick-fixes. We need something
to lure us out of the trap of thoughtless design, sloppy, easy
solutions and half-baked practices. The kind of thing that costs us
effort to do, but that in retrospect we're always glad we
have
done.
The spirit is willing, but when the deadline looms, all too often
the flesh is weak.
How do you think we'll achieve this?
Accountability counts
I
know that in my career to date, the single most import thing that has
encouraged me to work to the best of my abilities has been
accountability,
to a team of great programmers.
It's the other coders that make me look good. It's those other
coders that have
made me a better programmer.
Being accountable to other programmers for the
quality of your work will dramatically improve the quality of your
coding.
That is a single simple, but powerful idea.
Code++
To ensure you're crafting excellent code, you need people who are
checking it every step of the way. People who will make sure you're
working to the best of your ability, and are keeping up to the
quality standard of the project/team you're working on.
This needn't be some bureaucratic big-brother process, or a
regimented personal development plan that feeds back directly into
your salary. In fact, it had better not be. A lightweight,
low-ceremony system of accountability, involving no forms, lengthy
reviewing sessions or formal reviews is far superior, and will yield
much better results.
Most important is to simply recognise the need for such a thing;
to realise that you must be accountable to other people for the
quality of your code to encourage you to work at your best. To
realise that actively putting yourself into that vulnerable position
of accountability is not a sign of weakness, but a valuable way to
gain feedback and improve your skills.
How accountable do you feel that you currently are for the quality
of the code you produce? Is anyone challenging you to produce high
quality work, to prevent you from slipping into bad, lazy practices?
Accountability is worth pursuing not only in the quality of our
code output, but also in the way we learn, and how we plan our
personal development. It's even beneficial in matters of character
and personal life (but that's a whole other magazine's column).
Making it work
There
are some simple ways to build accountability for the quality of code
into your development process. In one development team we found it
particularly useful when the all coders agreed on a simple rule: all
code passed two eyes before entering source control.
With this as a peer-agreed rule, it was our
choice
to be accountable to one another, rather then some managerial diktat
passed down from faceless suits on high. Grass-roots buy-in was key
to this success of the scheme.
To satisfy the rule, we employed pair programming and/or a
low-ceremony one-on-one code review, keeping each checked-in change
small to make the scheme manageable. Knowing another person was going
to scrutinise your work was enough to foster a resistance to sloppy
practise and to improve the general quality of our code.
If
you know that someone else will
read and comment on your code, you're more likely to write good code.
This practice genuinely improved the quality of the team, too. We
all learnt from one another, and shared our knowledge of the system
around. It encouraged a greater responsibility for and understanding
of the system.
We also ended up with closer collaboration as a result, enjoyed
working with each other, and had more fun writing the code as a
consequence of this scheme. The accountability lead to a pleasant,
more productive workflow.
Setting the standard
When building developer accountability into your daily routine it
is worth spending a while considering the benchmark that you're
aiming for. Ask yourself the following questions:
How
is the quality of your work judged? How do people currently
rate your performance? What is the yardstick they use to gauge it's
quality? How do you think they should
rate it?
- The software works, that's good enough.
- It was written fast, and released on schedule (internal
quality is not paramount).
- It was well-written, and can be maintained easily in the
future.
- Some combination of the above.
Which is seen as most important?
Who currently judges your work? Who is the audience for your work?
Is it only seen by yourself? Your peers? Your superiors? Your
manager? Your customer? How are they qualified to judge the quality
of your handiwork?
Who
should
be the arbiter of your work quality? Who really knows how well you’ve
performed? How can you get them involved? Is it as simple as asking
them? Does their opinion have any bearing on the company's current
view of your work's quality?
Which aspects of your work should be placed under accountability?
- The lines of code you produce?
- The design?
- The conduct and process you used to develop it?
- The way you worked with others?
- The clothes you wore when you did it?
Which aspect matters the most to you at the moment? Where do you
need the most accountability and encouragement to keep improving?
The next steps
If you think that this is important, and something you should
start adding to your work:
- Agree that accountability is a good thing. Commit to it.
- Find someone to become accountable to. Consider making it a
reciprocal arrangement; perhaps involve the entire development team.
- Consider implementing a simple scheme like the one described
above in your team, where every line of code changed, added or
removed must go past two sets of eyes.
- Agree on how you will work out the accountability – small
meetings, end of week reviews, design meetings, pair programming,
code reviews, etc.
- Commit to a certain quality of work, be prepared to be
challenged on it. Don't be defensive.
- If this happens team-wide, or project-wide then ensure you
have everyone's buy-in. Draft a set of team standards or group code
of conduct for quality of development.
Also, consider approaching this from the other side: can you help
someone else out with feedback, encouragement, and accountability?
Could you become another programmer's moral software compass?
Often this kind of accountability works better in pairs of peers,
rather than in a subordinate relationship.
Conclusion
Accountability between programmers requires a degree of bravery;
you have to be willing to accept criticism. And tactful enough to
give it well. But the benefits can be marked and profound in the
quality of code you create.
Questions
- How are you accountable to others for the quality of your
work?
- What should you be held accountable for?
- How do you ensure the work you do today is as good as
previous work?
- How is your current work teaching you and helping you to
improve?
- When have you been glad you kept quality up, even when you
didn't feel like it?
- Does
accountability only work when you chose
to enter into an accountability relationship, or can it effectively
be something you are required
to do?
