Title: Coding Accountability

Author: Bob Schmidt

Date: 06 November 2019 18:25:33 +00:00 or Wed, 06 November 2019 18:25:33 +00:00

Summary: Pete Goodliffe looks at how we ensure we’re living up to our own standards.

Body: 

As iron sharpens iron, so one person sharpens another.
Proverbs 27:17

I go to the gym. Frequently. I’m getting older, and my waistline is suffering. Perhaps it’s guilt, but I 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 ranks marginally above hot pokers being stuck in my eyes. There are plenty of things I’d rather do with my evenings. Many of them involve sitting down, preferably with a large glass of red wine and some code.

But I know that I should exercise. It’s good for me. Is that fact alone enough to ensure I go regularly, every week?

It is not. 

I dislike exercise and would gladly employ the weakest of excuses to get out of it.

What unseen force coaxes me to continue exercising regularly when guilt alone can’t drag me out the door? What magical power leads me on where willpower fails?

Accountability. 

I exercise with a friend. That person knows when I’m slacking, and encourages me out of the house even when I don’t fancy it. That person turns up at the door, as arranged, before my lethargy sets in. I perform the same service back. I’ve lost count of the times that I wouldn’t have headed into the gym, or would have given up halfway had I not had someone there, watching me and working alongside me.

And, as a by-product we enjoy the effort more for the company and shared experience.

Sometimes we both don’t feel like it. Even if we admit it to each other, we won’t let each other off the hook. We encourage ourselves to push through the pain. And, once we’ve exercised, we’re always glad we did it, even if it didn’t feel like a great idea at the time.

Stretching 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.

We hear our industry experts, speakers, writers, and code prophets talk about producing good, well-crafted code. They extol the virtues of ‘clean’ code and explain why we need well-factored code. But it matters not one jot if, in the heat of the workplace, we can’t put that into practice. If the pressures of the codeface cause us to shed our development morals and resort to hacking like uninformed idiots, what use is their advice?

The spirit is willing, but when the deadline looms, all too often the flesh is weak. We can complain about the poor state of our codebases, but who do 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.

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.

When I look at other teams, when I review other software companies, it is increasingly clear that the stellar coding outfits – the organisations that really pack and punch – are those that hold each other accountable for code design and quality.

Code++

To ensure you’re crafting excellent code, you need people who are checking it at 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 you’re working on. (This is one of the reasons open source code is often of higher quality than proprietary code: you know that many other programmers will be looking at your work.)

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, no lengthy reviewing sessions or formal reviews is far superior, and will yield much better results.

Most important is to simply recognise the need for accountability; that being answerable to other people for the quality of your code encourages you to work your best. Realise that actively putting yourself into the 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 currently feel you 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 topic).

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 all the coders agreed on a simple rule: all code passed two sets of 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. Grassroots 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 practice 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. It encouraged a greater responsibility for and understanding of the system. 

We also ended up with closer collaboration, enjoyed working with each other, and had more fun writing the code as a consequence of this scheme. The accountability led 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 its 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 choose to enter into an accountability relationship, or can it effectively be something you are required to do?

Pete Goodliffe is a programmer who never stays at the same place in the software food chain. He has a passion for curry and doesn’t wear shoes.

Notes: 

More fields may be available via dynamicdata ..