Extreme Enthusiasm

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.

This entry was posted on 7 October 2010 at 09:49 and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.