I found myself in a session on refactoring legacy code. The session used a format that was new to me, and to most of the people in the room: a coding dojo.

Our objective, I think, was to take some very ugly, coupled code, add tests to it, and then refactor it into a better design. We had a room full of experts in TDD, refactoring, and code design. What could possibly go wrong?

One thing I learned in that session is the importance of the “no heckling on red” rule. I watched as Experienced Agile Consultant after Experienced Agile Consultant cracked under the pressure of criticism from the baying crowd of Other Experienced Agile Consultants. With so many egos in the room, everyone had an opinion about the right way to approach the problem, and nobody was shy of sharing his opinion. It was chaos!

We got almost nowhere. As each pair switched, the code lurched back and forth between different ideas for the direction it should take. When my turn came around, I tried to shut out the noise from the room, control my quivering fingers, and focus on what my pair was saying. We worked in small steps, inching towards a goal that was being ridiculed by the crowd as we worked.

The experience taught me how much coding dojo is about collaboration. The rules about when to critique code and when to stay quiet help to keep a coding dojo fun and satisfying, but they teach you bigger lessons about working with each other day to day.

Back in the pre-agile days when our projects were planned around component pieces of the architecture, “value” was a meaningless concept. The whole project had a value, but day-to-day that didn’t help us prioritise our work – from inside the plan it was impossible to judge whether my database stored procedure was contributing more value than your pricing component – without one, the other would simply not function.

As we started to plan around small deliverables like user stories, the concept of value came to the fore. Suddenly it was obvious that the “file saving” feature was much more valuable than the “conditional formatting” feature. This helped us immensely – we could prioritise our work around this value, and as a result actually felt the glow from knowing that the work we were doing was worthwhile, valuable even.

Now that value has become a first-class concept to software development teams, what happens when it becomes an obsession? When managers who can now measure value and velocity start to compare teams, or offer them incentives to deliver more, faster? When we as developers get so driven and focussed on the delivery of value that we forget to design, refactor, consolidate, reflect, and sharpen our tools? When we forget to go home on time?

We get burned out.

As ever, it’s the responsibility of the developers (and their leaders) to stand firm and hold on to the space and time that they need to do their work at a sustainable pace. Not all the hours you spend in a day – tidying up the build scripts, writing a code generator, cleaning up a library so you can release it as open source – can or should be directly attributed to the value they will immediately offer to the business. That’s not to say we should spend our days idling, but that we should maintain a level of self-respect in everything that we do.