Comments on: On discussions

By: Vic

Vic — Tue, 02 Nov 2010 17:05:27 +0000

Matteo: I was reading this in Carlo Pescio’s blog:
http://www.carlopescio.com/2010/11/design-structure-and-decisions.html
and your post came back to my mind.
I see some commonality, both with what you say and what I say.

By: matteo

matteo — Sun, 10 Oct 2010 20:55:52 +0000

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.

By: Vic

Vic — Sun, 10 Oct 2010 19:23:17 +0000

“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…

By: Luca Minudel

Luca Minudel — Fri, 08 Oct 2010 22:14:53 +0000

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

By: matteo

matteo — Fri, 08 Oct 2010 14:52:39 +0000

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.

By: jacopo

jacopo — Thu, 07 Oct 2010 20:29:40 +0000

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.