developer.*

The Independent Magazine for
Software Development Professionals

Hi Dan!

Just a couple of quick comments...

A quote from your essay "Software Design and Programmers":

I think you've missed the boat on this one... I haven't read McBreen's book, so maybe it's really he missed the boat. XP is not about shifting design responsibilities to the programmer at all. It's more about handing the design responsibilities back to the customer. The programmer (or development team, as a whole) works with the customer to help the customer design the system. Most customers need some assistance in learning how to design, so the programmers are highly involved in the process, but their involvement is only to assist the customer in making the final design decisions.

When XP says that "the code is the design" what they mean is that the source is the "design document." There is no need for an intermediate step of putting the design into the English language, formally, when the customer works so closely with the developers. The customer tells the programmer what he/she needs and the programmer translates that into code (more, specifically, the unit test code). When the programmer and the customer agree on the tests, the programmer simply goes off to implement the appropriate application code that will pass the tests.

In my opinion, the "specialist designer" should be more of a mentor to the developers. He/She should assist the rest of the developers in working with the customer to make design decisions. When the customer is away, this expert should be so familiar with the customer’s wishes that he can stand in for the customer in a pinch. He should also be experienced enough in the trenches so the developers have someone to ask difficult implementation design questions.

In my experience, I have found that programmers who do not go the extra mile and study such things as principles of design, alternative paradigms and methodologies, on their own, never really master their language, tools, and platform. These are the "nine-to-five" programmers who actually do leave their work at the office when they go home. They may have better family lives, on the average, but they are not better developers. (NOTE: I do think it is possible to have a very good family life and be a superior developer...I think I do and am...but, it's not common statistically to find people who do both well.)

Anyway... keep up the good work!

Ken LeFebvre
Mechanicsburg, PA
Ken's Blog

Daniel Read Responds

Thanks for your comments, Ken. I suspect that we are in closer agreement than it may appear. I suspect that it is mainly symantic differences that separate us. A key question appears to be, what is "the design"? Let's take a look at the example you gave, with the customer assisting the XP developer with the design. I am aware of this, of course, as a key tenet of XP. But the customer can only help with "the design" to a certain degree. The design that the customer can help with could be thought of as the "surface design" or "conceptual design."

I am fully in favor of this idea: working out UI design, logic flows, and even architectural issues in collaboration with the customer, with as much participation and empowerment of that customer as possible. I have used this approach many times on non-XP projects. But even when you maximize the customer's involvement, the design work the customer is either, a) interested in, or b) capable of, only goes so deep.

I think what you refer to in your letter as "implementation design" is more what I was thinking of as I wrote "Software Design and Programmers." So in my sentence, "programmers are responsible for the design of the system," you could read "implementation design" where I say simply "design." When the customer agrees, "yes, I like the way that screen works" or "that logic flow looks correct to me," the designer and/or programmer (depending on the project) is responsible for making a host of lower level design decisions--and I would posit that the vast majority of those decisions are of no interest to the customer whatsoever, even on an XP project.

In light of that, I'm curious about this statement from your letter: "When the programmer and the customer agree on the tests, the programmer simply goes off to implement the appropriate application code that will pass the tests." As I've mentioned before, I have not personally had the opportunity to work on an XP project, but I'm having a hard time picturing the customer being interested in or capable of evaluating and approving object method-level unit tests. Even if we're talking about UI-oriented tests, the tests themselves would necessarily be complex because of the particularities of UI frameworks, such as Struts.

What I can picture is a developer and customer working out a list of unit tests so that the customer can give his approval that the list of tests appears to be comprehensive, but I expect the developer would still need to make an effort not to bog down that list with too many low-level details--which suggests that there are yet more detailed tests to be specified even after the customer gives his approval; I'm picturing tests for things like boundary checks, data type verification, threading issues, etc. Not to mention, the developer will hopefully recognize many more necessary tests as he writes the code.

So perhaps we have a disconnect as to what exactly "the tests" are when you say "the programmer and the customer agree on the tests."

Thanks again, Ken, for your input. I'd also be interested in hearing from others on these matters. Given my lack of direct experience with XP, I have an open mind.

Sincerely,
Daniel Read