On discussions

I know a developer who says that he enjoys discussion during pair programming. He says that it’s one of the ways to learn and grow on the job.

I disagree. Here’s why. Discussion is waste. In the sense of Lean, discussion is a non-value adding activity. Consider coding and discussing. Do they add value? How do you tell what is waste and what is value-adding, anyway? After all, if you don’t discuss things with the customer and with your collegues, you can’t arrive at a functioning release, right?

David Anderson in his Kanban book explains well, IMHO, how to tell waste from value-adding. Suppose that discussing is value-adding. It that is so, let’s do it to the max! The more, the better. Do the same thought experiment with coding. If coding is value-adding, then let’s do it to the max! Which of the two rings more true?

I have this image in my mind. Consider when you release a feature to the customer. The release is made of lines of code you added, changed or deleted. The value-adding activity was in writing those lines of code. Everything else is waste.

I understand that programming is not typing, and that thinking is the most important activity that happens while we work. Yet, this thinking is waste. Suppose that you can code a feature without much thinking, because (for instance) your team has standard ways of dealing with this sort of features, or you did similar things years ago, and you know how to code a solution. This position is better than the position of someone who does not know how to proceed, and has lots of choices and doubts and has to think.

So if you don’t know how to solve a problem, by all means, think! Step away from the keyboard, consult books, discuss at the whiteboard, ask in forums, look in your codebase to see how this problem was solved before. All these activities are necessary waste. Just don’t charge heads down and try to code yourself out by brute force. That would be probably more wasteful.

You see, not all coding is value adding. Only the coding that produces the lines of codes that will make the release is value adding. Spikes, refactorings, false starts are all (perhaps necessary) waste.

I have not become convinced that iterative development, small steps, refactoring are to be avoided. I’m not advocating doing some big upfront design to make sure we can hit the release code without iterating, without incrementing functionality bit by bit, without refactoring. I still think that iterative and incremental design is the only reliable way to produce good software. But we must remember that refactoring per se is waste. Francesco Cirillo is fond of saying that emergent design is not “doing some messy work now, then I will refactor”. It’s more efficient to write incremental code that can be extended without refactoring; it’s more efficient to exploit the Open-Closed Principle!

Let’s get back to the subject of discussions while coding. My opinion is that programmers either know how to proceed, or they don’t.

  • If they don’t, they should do spikes, study, think, stop pretending they are doing a pomodoro of coding and call it a pomodoro of studying.
  • If one of the developer thinks he knows how to proceed, he should be the driver, explain to make sure that the navigator understands, and then do it. The navigator’s job is to make sure that the driver has a reasonable understanding of the problem, and he’s not doing something that is probably/obviously/previously shown to be a dead end.
  • If both developers have a differing idea, then my friend says they should discuss the relative merit of both points of view and come to an agreement to what to do. I disagree. This is pure waste. I think that it’s more productive to choose one of the two ideas and see how it turns out. That is worth more than all the discussion in the world. Choose quickly; challenge the other saying things like “I bet I can solve it cleanly in 4 pomodori!”.

The navigator’s job is still to support the driver, not to challenge the driver’s idea. That would take energy away from both. If the navigator thinks that the driver’s idea might work, he or she should support the driver and accept that the thing will be done differently. Now this will help both grow and learn, more than discussing. Just remember to respect the other, and always explain clearly what your idea is.

6 Responses to “On discussions”

  1. jacopo Says:

    Matteo, pair programming isn’t pair coding: spiking, looking for answers online *and* discussing is part of the development cycle. If you think doing alone you could miss simplicity, or courage, then it’s worth doing in pair.

    I don’t get the value as line-of-code thing. Given I’ve got 100 lines of code right know and I should add functionaly X, if removing 90% of those LOC adding new beavihour gets simpler, that’s value added, I think. If removing those 90 lines took 1 pomodoro of iterative refactoring (me, then my pair, then me again with a new idea) that’s still value added.

    Waste is *useless* discussion, the one which ends with nothing done. How do you know when disccussion is getting useless: timeboxing to the rescue..

    In my (humble) opinion, starting a pair programming session with someone telling me “I’ve done this 10 times before” (and everytime in the same way) does not help: I would react with “so, let’s do it differently!”. That’s even a better bet, for both.

    Anyway, pair programming is probably one of the hardest XP practices: it does not ask you to change *just* your job habits, but you as a person.

    Thanks for sharing these thoughts.

  2. matteo Says:

    Hi Jacopo,

    Thanks for your comments.

    I acknowledge that I’ve been doing very little programming lately, pairing or not. You have a point about doing things *always* the same way. But I am worried about the other extreme; the danger of doing things always differently. The Toyota people say that you can only improve a process when the process is standardized. I think that the team can’t improve their coding if they don’t set a baseline of accepted solutions to improve upon.

  3. Luca Minudel Says:

    time to time as a pair-programmer I made unnecessary discussions that was waste in the sense you described here, if I get this right.

    and time to time the programmer pairing with me did unnecessary discussions.ยด: waste

    in many of those situations the reason was the simple fear to act and then looks at the results and judge then.

    the tools that worked for me to encourage action was
    – technical: small changes, frequent check-ins, easy low costs roll-backs
    – social: the facilitator tools about non judgmental listening

    I like also the opinions you listed in the post

  4. Vic Says:

    “Suppose that you can code a feature without much thinking, because (for instance) your team has standard ways of dealing with this sort of features, or you did similar things years ago, and you know how to code a solution.”

    Oddly enough, before the agile frenzy we would have said: if you can code something without thinking, if you have already done the same thing, if you have a standard way of doing that, then you you should have (or build) a reusable component / library / something to handle the repetitive parts. Therefore, think, not code.

    I consider my time wasted when I write rote code; I’d rather spend that time thinking on what I need so that I don’t have to write that code anymore…

  5. matteo Says:

    Vic: I’m not saying that we should spend a lot of time writing rote code. If you have a standard way of doing things, that standard should be embodied in some easy-to-use library. The point I’m trying to make is that you’re in a very good position when you can code *anything* that the customer asks you by simply connecting existing pieces. Getting there requires a great deal of thought! But my goal is to be able to do what is required of me without having to think. Well before Agile was invented we used to say that the goal was to reduce the number of things that require thought, by inventing ways to *calculate* solutions. That’s the same spirit.

  6. Vic Says:

    Matteo: I was reading this in Carlo Pescio’s blog:
    and your post came back to my mind.
    I see some commonality, both with what you say and what I say.

Leave a Reply