There is always that guy. The business oriented guy, the guy who can’t understand why a few lines of code can take a whole day to produce. The guy who believes that pair-programming is the equivalents to “get one pay for two”. This is a story about that guy and how I made him understand.

A few years back I was involved in in a project that had the attention of a vice president in a huge enterprise. The project had haltered and the VP’s response was to micro-manage developers tasks. One of the meetings I was asked to prepare was to explain why a switch in data access technology had to be done. A gruesome task: Explaining technology limitations to someone with absolutely no technology background. In the end it succeeded. Turning technology limitations into pure numbers: Bugs/LoC, Cost of a Bug, hours spent on performance tweaking, etc., etc.

But that is not what this post is about. This post is about how I got him to understand that developers are not glorified copy writers with the task of writing as many letters/day as possible:

- “I don’t understand? How can you only produce 100 lines of code in a full day? And that’s with two developers at the same keyboard!”

- “You write business plans right?

- “Yes.”

- “And how long is that document, about 30 pages?”

- “Yes?!”

-“I can write 30 pages of text in Word in a day, maybe half a day. How come it takes you weeks to produce the business plan?”

-“Isn’t that obvious? We need to figure out what the business plan is about, the text is just a documentation of our thinking.”

-“Exactly”.

From that point on there were no more discussions on lines of code, technical details or design/architectural decisions. From that point on it was only about features and velocity, process and predictability, and the most important feature of them all: delivery.