January/February 2018 issue of acmqueue

The January/February issue of acmqueue is out now

Kode Vicious


  Download PDF version of this article PDF

ITEM not available


Originally published in Queue vol. 8, no. 3
see this item in the ACM Digital Library


Follow Kode Vicious on Twitter
and Facebook

Have a question for Kode Vicious? E-mail him at [email protected]. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.


Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.

Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.

Ivar Jacobson, Ian Spence, Pan-Wei Ng - Is There a Single Method for the Internet of Things?
Essence can keep software development for the IoT from becoming unwieldy.


(newest first)

Dan Cross | Sun, 26 Aug 2012 15:29:46 UTC

Peer pressure should not be confused with shaming, which is always essentially negative. Indeed, one of the first lessons of leadership is "praise in public, criticize in private."

Rather, creating an environment where it's okay for one to take public responsibility for an error is far more effective. Ensuring that peer pressure is constructive can be used towards this end, as can good-natured competition (I like Paul Murray's example of the toy duck). Everyone makes mistakes and it is the mark of a healthy environment and a strong leader when one can acknowledge those mistakes to others in the organization. Making someone feel ashamed of making a mistake is neither scalable nor conducive to the long-term health of the organization.

Paul Murray | Tue, 08 Mar 2011 05:27:23 UTC

I worked at one site where whoever had most recently broken the build had a duck (not a real duck, obviously) put in their cubicle. It was a triumphant occasion to pass the duck along to someone else.

Peer pressure, and a sense of professionalism and pride in your work. Each team member must internalise the value "I do not screw up everyone else's day by breaking the build".

Vijay Narayanan | Tue, 13 Apr 2010 00:55:41 UTC

Very useful article! I want to add that broken builds could also be due to too many manual steps in setting up development environments. There is always the temptation to "do the minor fix" but not go all the way- why go through the trouble of compiling the rest of the code, deploying, and verifying? When I hear a developer say "my dev environment is not setup" for days and weeks - that is a warning sign that the build might be too complex, manual, and error-prone. When you script the environment setup and the build process and start creating automated tests - it just makes the entire team more productive.

David Rogers | Tue, 30 Mar 2010 22:29:43 UTC

Great article! I would like to add that if the offender is unable to build the project with their changes before checking in those changes, you have an infrastructure problem. If they are technically able to build with their changes, and don't, you have a disciplinary problem.

Juan Manuel Trejo Sánchez | Thu, 18 Mar 2010 20:35:46 UTC

I think one important point here too is culture at work. When there's considerable time spent on discussions on how it is your fault and not mine, and not in actually solving the problem, there's more likely no will to agree something has to be improved, nor to propose how to improve it, volunteer to collaborate on the improvement or accept the changes derived from it.

What I mean is having a culture of feedback and openness where nothing is ever personal also need to be enforced. It may sound an ideal case yet it's possible: A culture where people know they are being evaluated always on their work and not on themselves, where feedback is intended for improvement and enforces constant improvement. Where people are not defensive, having to lie or argue to avoid feeling ashamed or being labeled, or even avoiding responsibilities.

That way people will feel safe and be open to improve, and will be motivated to help achieve the goals.

It is hard to push for any change in infrastructure, architecture or attitude when people are prone not to collaborate and are more worried about their own image and reputation.

These are my two cents, I love the way you explain things here, Kode.

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.