Two heads are better than one

Yesterday I had a conversation with a consultant where we started talking about having two displays on a computer. The reason it came up is because my development box at work has two displays, and he was impressed. I quoted a study that I had read somewhere (and need to look up) that claims a developer is 40% more efficient when using a two-headed display setup on a computer compared with a single-display. This study was done over a decade ago, so the new giant single-screen displays may throw off the percentages, but the idea is still sound: having a bigger picture is better.

This made me think about pair programming again. (Didn’t mean to have two posts about the same subject, but here I am.) Two heads are better than one there too, and I don’t doubt that you get better than a 40% effiency from two people working on the same problem. Studies show that you hit that 40% level after just a few days, and you get the added benefit of less-buggy code so the long-term win is a substantial multiplier.

TDD, Pair Programming increase productivity via “quality”

After reading How TDD and Pairing Increase Production, I found myself thinking about the distinction between “internal” and “external” quality. I agree with Mike Bria’s assertion that “Quality” isn’t really a sufficient term to capture the essential properties of good code, nor is it really the right term to use for a good product.

Good terminology makes it a lot easier to think about things, so I think this idea of “internal” and “external” could use quite a bit more exploration. We could refer to the “internal quality” as how well-engineered the code is; that’s at least a starting point. (If you wanted to frame it negatively, you could call that the code’s “defectiveness”; personally I’m not in favor of that framing mechanism.) The idea that a well-engineered product is easier to maintain sounds pretty obvious to me; hopefully it would to a casual listener as well.

In my mind, “external quality” is a combination of the value that the product brings to the user, its usability in the HCI sense, and its ability to be used in scenarios not considered by the developer (which in itself has several aspects). That’s much harder to define succinctly, but fortunately it is also easier to communicate to stakeholders than the engineering side of the equation.

So well-engineered, valuable, usable, and flexible/extensible/leverageable products should be our goal. How do you say that latter part more briefly and clearly? Well-implemented? (That’s not clear, but at least it is relatively brief.)

The original article’s assertion that well-engineered code makes for more productive programmers is an excellent point. I would further say that the well-implemented product has the same effect for its users. Unfortunately poorly-engineered, poorly implemented products are still the norm in software development.

I need to do more research into appropriate terminology for these concepts.

Left brain, right mind: Pondering details to see the big picture

Referring to the old left-brain right-brain dichotomy in a new way.