Coders Dont Develop Software

The unfair accusation levelled at XP proponents that they leave many of the most problematical aspects of SoftwareDevelopment out of the equation. This can't be true, because then no XP projects would deliver, but the disdain shown for non-coders in ArchitectsDontCode and AuthorsDontCode seems disproportionate.

I think what you see is frustration with those who theorize but never practice. Being far away from the practice makes it harder to see what needs to be changed. The difficult aspects of development that you mention above may not be necessary in the practice of certain projects. In others they will be necessary and any good team will include them when they are.

This is true but being far away from the practice can make it easier to see where something is wrong. I'm working on a name for this kind of paradox. Any thoughts?

[Do you mean a FreshPairOfEyes? --DavidPeterson]

"Its probably more useful to be a coder than the guy who knows what is wrong."

Curious logic. If you restrict utility to producing good software (sad, I know) then the most useful guy on the planet at this moment in time is the guy who knows what is wrong. Of course, if you're the coder and you think your code's fine, then he's the last person you want to hear from. But objectively, it's better you do.

I don't think you'll find too many programmers around here who think their code is perfect and doesn't need improvement. If someone truly knows what's wrong, and how to fix it, that opinion will be valued. But those who believe problems can be fixed by BigDesignUpFront, extensive-but-useless documentation, or draconian methodologies are often making the problems worse, or hiding them, rather than making them better.

While the disdain shown for non-coders in ArchitectsDontCode and AuthorsDontCode may seem heavy, it is more reasonable than the disdain shown for coders by those who think that creating box-and-arrow diagrams or Gantt charts is the really hard part of software development, and that coders are just overpaid trained monkeys.

I don't understand the title: If coders are not developing software, then who is? Or what are the coders doing that is not SoftwareDevelopment? Or is it that coders alone don't develop software?

-- KrisJohnson

Now there I wouldn't disagree with you. I think the really hard part about SoftwareDevelopment is deciding what the software should and should not do for the enterprise. It's a collaborative effort in which no-one's genuine contribution should be disdained. Personally, I've never found a use for Gantt charts, but box-and-arrow diagrams are great, especially on a whiteboard. Maybe some problems can be fixed by BigDesignUpFront, or ThinDesignOverTheTop? and round the edges: all methods are inappropriate some of the time, so maybe no method is inappropriate all of the time. This is my thesis (the paradox above), which I'm going to refer to as MultiplePerspectives?: the more the merrier!

Box-and-arrow diagrams are great, for limited purposes. They are fine for informally describing how system components interact, or for other illustrative purposes. But all too often, somebody with authority but no coding expertise will draw a few boxes and arrows and then say to the coders "There, that's the design for your system. Now all you have to do is implement it that way." When coders ask questions, the architect just draws the same box-and-arrow diagram again. When coders find a way to provide the functionality in a way that does not map to the boxes and arrows, the architect complains that it wasn't done properly. That's the all-too-common situation that leads to ArchitectsDontCode-style venting of frustrations.

It's not disdain for non-coders--it's disdain for non-coders who insist upon dictating the internal properties that the code must have. It's also disdain for those who focus more upon generic abstractions and ideals rather than the specific problem that the coders are responsible for solving.

I observed something like this in my first job after college. I'd come into development and maintenance of an insurance company billing system maybe six months or so (not sure) after it went into production. The designers were pretty inexperienced and most of them had never programmed--they were "business analysts" after all. The billing system they came up with closely mimicked a "tickler" system, in which payment records were made for a new policy as it was written, and any under- or over-payments were distributed over the remaining bills in the sequence. When policy premiums were changed mid-term as a result of endorsements (coverage changes, etc.) those adjustments were also distributed over the remaining bill records. Of course we programmers were going crazy with special cases, superfluous date calculations, and dealing with rounding of pennies. The system hadn't quite gotten to a literally unmaintainable state by the time I arrived, but it was being held together with superhuman programmer effort and a lot of folklore. All because of a design model that was ignorant of the nature of databases, disdained relational theory, and discounted (even then, in 1988) the cheapness of CPU cycles.

I agree that deciding what the software should and should not do is the hardest and most important part of any software development effort. XP (correctly, in my opinion) addresses this issue by putting that responsibility on the Customer rather than on the coders. The Customer says "I want the software to do this", and the coding team makes it happen. The coding team doesn't tell the customer how to run the business, and the Customer doesn't tell the coders what internal structure the code must have.

So, in XP, the trick is finding Customers who know what the enterprise needs and coders who can make it happen. This is a much more reasonable course than trying to find people who know (or dictate) exactly what the enterprise needs and also how to make it happen.

-- KrisJohnson

I don't think assigning responsibilities is a way of addressing a problem, though it may be a necessary first step. The point is that software developers are usually much better than the customer at seeing why what the customer is asking for is not what they really want. If the customer knew what they really wanted, they would ask for it, of course (most of the time). They really believe they do want what they are asking for, so it is rarely easy to persuade them that something else would be better. But that in itself is no reason not to try.

Having said that, no-one should try to dictate the internals of software without providing justification. If the justification is missing or the costs outweigh the benefits, there is good reason to reject the suggestion. This can be a difficult debate but it is ultimately about making a decision based on what's best for the customer rather than dismissing the suggestion because of whom it came from.

The reference to customers leads directly to two common observations about customers (that probably belong on AnotherPage):

It's just what we asked for, but it's not what we want.

and

Sometimes it's easier to give the customer what they ask for instead of explaining to them why it's not what they want.

-- DirckBlaskey

I think that first observation is too rosy picture: customers never admit that they got what they asked for. A common case is that the customers don't realize or won't admit that they've been given what they asked for, and blame the coders for the undesirability of the delivered solution. I think that's one of the good things about XP: it involves the Customers directly to ensure that they understand and take responsibility for what they've said they want. Some see this as a way for developers to avoid responsibility, but I think it's the only way that really makes sense. If the customers don't know what they need, how can anyone expect developers to figure it out? And why do so many developers believe that they understand the customer's needs better than the customer does? It's usually best to give them what they ask for, and let them figure out on their own whether it is really what they need and whether they want something else instead. -- KrisJohnson

Unthinkingly providing just what customers ask for is not the right approach. Neither customers nor developers necessarily know what's best. You need discussion. Customers probably know their business better than the developers know it, but do not always know what technology can make possible. Developers (indeed any intelligent outsiders) can often bring fresh ideas and a fresh outlook. It would be irresponsible for the developer to put all the onus on the customer for coming up with ideas. -- DavidPeterson

I'm not suggesting that there be no thinking nor discussion, or that ideas can't come from anywhere. But the decisions for feature set should belong to the customers, and the decisions for implementation should belong to the developers. -- kj

An advantage of XP is that the customer can find out quickly if what they asked for is or isn't what they want - and if you have a customer that's a regular part of the process, they will be more willing to listen to the developers explain why what they said they wanted may not actually work for them. Developers can sometimes poke logic holes in requirements; the customers are best served by paying attention when that happens - but with a quick process, it may work better if you can show them instead of tell them. -- DirckBlaskey

How do you control bias? Is it the case that XP asks the OnsiteCustomer to assume the role of SystemAnalyst? And if this is so, can you really find a customer who is knowledgeable of the complete problem domain (in terms of culture, organizational roles, procedures, BusinessRequirements, external pressures, trends etc.) and isn't too busy running the business. Choose the wrong XP customer and you may end up with a system that satisfys only one person or role. Now I think about it, WrongCustomer? could become a common downfall of XP projects (see CthreeProjectTerminated). The problem could be stated simply as, OnsiteCustomer vs. OnsiteDeveloper?.

In fact, look at TheMythicalXpCustomer. That puts it better than I did.

-- ChrisSteinbach''

[From above]

This is true but being far away from the practice can make it easier to see where something is wrong. I'm working on a name for this kind of paradox. Any thoughts?

Being a certain distance from a problem can help to put it into perspective, granted. The practice itself also needs to be improved and I agree that it can be easier to see a problem from the outside than from the inside. It's sort of like the Taoist "finger pointing at the moon". If I look at the finger, I can't see the moon but if I look for the moon I can't find it because I can't see where the finger is pointing. If I practice too much, I can't improve because I'm not examining my practice, but if I spend too much time examining and theorizing, I will lose touch with the original practice. If one does too much of one or the other it can be bad.

Progress happens when people are thinking and doing things. Some people think about thinking better, or think about doing things better, and this improves things and aids progress. But when you have people thinking about thinking about thinking and doing, then you start to get diminishing returns (and lots of ridicule from the thinkers and doers).

This is like the dichotomy between academics and practitioners. Each group has its frustrations with the other. But as said above, you get the best results from mixing and modulating, not from drawing the lines stronger.