Code Retrospectives
I bet that most of the people who read this blog have been through a code review at some point – a session where a bunch of people get together, look at a piece of code, identify all the things they consider problems and document them. Then the developer goes away and fixes all the problems.
Usually these reviews are relatively infrequent, time consuming, and exhausting. The focus is on finding errors and correcting them, and I know that when I was having my code reviewed this way I found the process quite stressful as well.
I think this model of reviews is pretty much broken. These days I want to get “code reviews” done at least a few times each hour, whether there’s anyone else around or not, and the only way to get that is to use automation. In the Java world, tools like Checkstyle, Simian and Complexian provide a wealth of checks – far more than a human team could check in any reasonable amount of time. And despite the names these checks aren’t just “style” checks – they help you enforce metrics thresholds as well (which is a separate discussion). Plus there’s much less emotion associated with feedback from an automated tool, and the tool has infinite patience.
Once significant chunks of what’s covered by traditional code reviews have been handed off to automated tools, the humans are free to use code reviews in a different way. Instead of looking for mistakes, the team can look for opportunities to learn. Accept that the code is the way it is, that everyone was doing the best they could at the time, and review the process that created the code rather than the code itself, all the way back to the root cause. Certainly you’ll find some things in the code that must be fixed before you move forwards, but lots of things will be tolerable if you can fix the process so that they don’t recur.
In this context, “process” is a broad term – it includes the way you hire people, the training you give them, the tools, the incentives, the requirements; anything that might impact the final code. The Toyota “Five Whys” can be a good way to get to the root cause. (make some note in here)
At this point we’ve transcended code reviews – what we’re doing is far more like a retrospective, focussed tightly on our code. Although retrospectives are usually associated with ends of iterations and releases, we can use code retrospectives much more often.
So instead of treating your code reviews as opportunities to find the mistakes that your colleagues have made, switch to code retrospectives and improve the process that created the code.
Two thoughts:
Pair programming is often said to be an ongoing code review – meaning every line of code typed, every idea created is immediately reviewed. Have you found this? How well does it work?
Devil’s Advocate…
The downside to analysis.. What if the team finds problems in the process they are powerless to change – due to budget restrictions, different value systems, or that it occurs in a different department.
Isn’t that a bit of a downer? To know that you’ll encounter it next project and the one after that, and that you are powerless to do anything about it?
Would it be better to live in the muck of blissful ignorance?
Pair programming works very well in the way you describe. It’s not appropriate for every team, and even with pair programming I think you can be retrospective about code in a wider audience (I’m very opposed to pairing combined with traditional code reviews).
With regards to the second point, I think there are two important considerations:
1) The organisation’s primary goal may not be effeciency of software development. This come as a shock to programmers. So it’s not *always* appropriate to make changes that would benefit *software development*. People need to have the bigger picture in mind, but to do that you need to know what the bigger picture is, and analysis may help with that.
2) As Martin Fowler is quoted as saying (I can’t find the actual quote) “if you can’t change your organisation, change your organisation”. If the things you can’t change really distress you, find another place to work. If that’s not possible, acknowledge that you’re not a slave, so you could work somewhere else, but there is something positive about where you are that keeps you there, even though there are things that aren’t ideal.
Sage advice.
The organisation’s primary goal may not be effeciency of software development.
What!! Since when.
Going on from point 2..
In your opinion, what responsibility does an organisation have to make things ideal for the people it employs. (Ideal being defined as ’supportive’ of the employees own goals and values’)
For example, some organisations take this very seriously. I’ve worked in organisations that offer free limited counselling, easy job-share arrangements and systems to prevent people being overworked and bullied. These systems include having specially designated counsellors for people to go to if they feel they are being bullied, and having a lights off/home time at 5pm policy.
I have worked in other organisations that have non-ideal setups for their employees. For example, they will work people so hard their health deteriorates, or prevent them spending any quality time with their family and friends. Any complaints are met with the reply “Lump it or leave it.”
In your opinion, how responsible is an employer for ensuring that the work conditions which an employee works under are ideal?
I’d love to hear your thoughts.
The quote reference is here:
http://www.martinfowler.com/articles/xp2000.html
You probably didn’t find it because you were searching for orgnisation with an ’s’ rather than with a ‘z’.
I take the narrow view of employer “responsibility”. Employer’s are responsible for abiding by the laws, and creating a profit to their owners – that’s it. If we want employers/companies to have broader responsibilities, we should, as a society, put them in legislation. If an employer concludes that the best way to turn a profit is to create non-ideal setups for their employers then fine for them, and I think it’s unrealistic to expect that this won’t happen.
That said, I think that many employers find that the best way for them to make a profit is to retain good staff, because there are high costs associated with turnover. So while I don’t think that they have a “responsibility” to create a pleasant environment, I think it’s in their *interests* in many cases, and that employers who refuse to do so may be quite short sighted.
I also believe that more rights for employees should be protected by legislation, and that history gives plenty of examples of what happens when this isn’t done, but now I’ve crossed the line from software development to economics and on into politics, which might be a little too far.
It makes good sense. I really enjoyed reading your response.
crossed the line from software development to economics and on into politics
No software application is developed in isolation of economics and politics. Ignoring their influences on the development can be a very costly mistake.
Actually, I have another question I wanted to ask you:
Suppose there were 3 companies.
Company A is a sweat shop that ignores the law. People work 60hr weeks for below minimum pay, bullying and sexual harassment are rife. Employees are poorly paid.
Company B follows the law and is nice to its employees. There’s no bullying, everyone works 40hr weeks, everyone is treated with respect. Pay rates are at industry average.
Company C is the employee’s ideal company.
For example, if they don’t want to work with someone, or on a certain project, because it doesn’t interest them, they don’t have to.
If they want to cut down their hours for a week, so that they can spend time with a friend who’s come in from out of time, they can.
If a client pisses them off, they can walk away from the project.
Using your thought, So while I don’t think that they have a “responsibility” to create a pleasant environment, I think it’s in their *interests* in many cases, and that employers who refuse to do so may be quite short sighted.
Company A is more short sighted than B – as A will have higher staff turn-over and a fair number of OH&S incident reports to deal with. Over time, B will be more profitable than A.
Using this logic, doesn’t it also follow, that over time company C will be more profitable than B?
Love to hear your thoughts.
Note: “a friend who’s come in from out of time” should read “a friend who’s come in from overseas”.
Although, I wouldn’t mind some friend coming to visit me from the future.
My answer is “it depends”, in both cases. Company A might be more profitable if the law was weakly enforced. I’d *hope* company C was more profitable, but I also think there is a line where catering to employees becomes indulging employees, and while most people respond well to “good employment conditions”, some people will take advantage of them. There are challenges in creating and maintaining these environments.
But the following:
* To work on projects that interest me
* To work with people – both colleagues and clients – that inspire me
* To have control of when I work and how hard I work and what I do with my time
are huge determinants of my happiness as a person and my growth as a developer.
Are you saying when I join a company, I’m placing the determinants of my happiness and self-development in the hands of someone who may be making decisions based on legal and economic grounds? Rather that what is best for me? From my perspective, that’s crazy.
What would stop some executive saying, “Well we could set up systems which help David and his colleagues grow as people, or we could just wangle up some more profit by working them into the ground. Let’s go for the second option.”
This would put a big spanner in my happiness – as I would be overworked and unable to spend time with my friends and family, or writing coments on your blog.
So it seems crazy from my perspective as a prospective employee. Why would I take up an offer to put my happiness in someone else hands? Your thoughts?
Certainly you’re putting the things you list in the hands of someone whose decisions reflect different criteria to yours. I’d hope that these aren’t the only things that determine your happiness as a person, but I concede that they’re probably significant. Another thing that’s probably influencing your happiness is your financial security, and that’s the bargain (potentially a Devil’s bargain) that you’re entering into. If it’s any consolation, from the employer’s side they’re putting their economic future in the hands off someone who might just want to be happy, and they may not be happy about that!
An alternative is to go open source and live off the land…
There are other alternatives. I found this post:
http://codecraft.info/index.php/archives/78/
The two suggestions I liked more in the comments were:
If you are a good programmer, you can take fixed price jobs, suited to 4 or 5 people, and develop them as a single person. Hence, you get 4 or 5 people’s pay as pay off for your skill and expertise.
Also, there is a model for a business – based on experts leading juniors – in the final comment which is interesting.
—
In my thoughts, I believe it is very important for every person employed to ask themselves:
What does my employer actually give me? And can I get it cheaper through another structure?
For example, if your employer doesn’t give you training and benefits other staff at other companies enjoy, you may be better off contracting your work to that employer.
Or, if they only provide you with customers to work with, and put money in your bank each week, you may be better off getting a website to promote yourself and an accountant to do your books.
Similarly, to future proof their company, an employer must ask themselves – am I providing value to my staff which they cannot get cheaper any way else?
If the staff start setting up new and better ways for themselves – which don’t profit the employer – then traditional employers will struggle with maintaining their workforce.
But I see Cogent has already taken a step against this – in that it is in part based on a dissociated network of developers.