I like this Extreme Programming stuff. A lot. So, like most things that I care about, I'm interested in challenging some of the views about Extreme Programming in the hope that I can improve my own understanding and maybe help to shape the shared understanding of it. XP loves bold statements, so here's mine:
Let's kick it around and see whether it stands or falls:
Two of the central tenets of XP are You Arent Gonna Need It and Do The Simplest Thing That Could Possibly Work. But the people who buy software aren't usually the people that use it and they are always sold on the things that no-one really needs. He says, "Wow Sentence99 lets you do virtual reality visualization of memos - cool," and rushes out to buy it for his secretary. He plays with the VR plug-in for ten minutes; his secretary never uses that feature at all, but he bought it. Also, if we built our products so simply that anyone could figure them out, how would we make our consulting revenue? Sure, XP may be good for in-house projects but Extreme Products Wont Sell.
-- Paul Dyson
That sounds like a variation of the individual job security pattern IfIWroteMyCodeSoThatAnybodyElseCouldUnderstandItThenTheyCouldFireMe -- Alan Knight
YAGNI is for the programmer, not for the customer, at least in the XP context. The customer may ask for things that he wants and later realize he doesn't need them. That's ok. He is paying to get what he wants, not what he needs. If he wants to have what he needs, then he needs to forget what he wants and get what the competition has. The competition has what he needs, because HE CAN'T BE FIRED FOR DOING WHAT THE COMPETITION DOES. "Those guys are doing the same thing, so we must be right". Namely buying a world-class system and firing those silly programmers.
I think that You Arent Gonna Need It really deals with Development adding in generality that is unneeded, or in other ways going off on tangents that the people playing the role of Business don't need.
It seems that for software products, you'd have marketing playing the role of Business, and of course they'll need VR.
Regarding simplicity, I just wonder whether there is always correlation between internal structural simplicity and the appearance of simplicity at the user interface. A spreadsheet program, for instance, goes to great lengths to appear simple, er, sometimes. But when you get inside and discover that the appearance of an infinite area of cells is handled quite differently as a data structure (and it may be simple or not)...
I'm not sure You Arent Gonna Need It can be restricted to Development in this situation. I work in a product company (although not building a shrink-wrapped, shelf-sold, product) and our client is essentially the marketing dept. (represented by the company MD). Because we aren't driven by a need to fill a hole in the business, a lot of the requirements are very fuzzy and any developer who says 'well I could also do X and Y with a little more work' is usually met by a great big grin because they are adding functionality at 'reduced' cost. I'm not sure there is a marketing dept. that will state things as clearly as 'we need VR' and this makes it very difficult to introduce a culture of YAGNI at the development level. And if you do introduce YAGNI at the business/marketing level (something that I believe is an implicit requirement for an XP project) then the product wont sell.
As concerns doing the simplest thing - I think simple models do shine through to the UI. And it's not just about the UI. We develop in Smalltalk and the source code will form part of the sale of the product. If the client's developers can easily understand our code then they don't need to keep coming back to us for improvements and enhancements (perhaps stuff they really do need :-). Bang goes one revenue stream.
-- Paul Dyson
YAGNI is, emphatically, a rule about what developers should do. The XP practice missing in your situation appears to be that the customers (marketing department) have not set priorities on the stories. The customer responsibility is to set priorities of H (must), M (very important), L (forget it) on all stories, and to define for each iteration which stories are to be done in that iteration (load permitting).
The effect of doing that is that the customers are forced to choose what not to do, in two ways: first, they put off stories in favor of other stories, thus breaking priority ties almost painlessly; second, toward the end of the implementation, they will be in a position to remove stories from the queue so as to make the date (or to leave them in, explicitly blessing date extension).
YAGNI says, it never makes sense for a developer to implement things that aren't asked for. It is always an explicit waste of the company's money. It does not save money over doing the same thing later: the cost is the same, just spent later, which is a good thing. Making the marketing guys grin will not put money in the company's pocket.
The core problem in your situation, IMO, is two-fold: first, if you have fuzzy specs, you'll get a fuzzy product. Explicit user stories, prioritized and delivered to the iteration by marketing will reduce fuzziness.
Second, developers shouldn't implement unrequested functionality in any case, because priority setting is in the customer role. Customer should choose functionality for the product primarily based on user value, not on convenience of implementation. The time spent implementing the additional features might be better spent on something someone actually wanted, and it's the customer's job to determine that.
Just my opinion, of course ... -- Ron Jeffries
Marketing people don't always know what is technically possible. They know what other products do, and they know what customers have asked them for, but they don't know what else is possible. I don't think innovative products come from marketing. Consider the very first spreadsheet, or the Sony Walkman. (Maybe this is different in payroll.)
It's not so much you're not getting paid for it, because sometimes you are. It's that you have to keep this role separate to the implementation role. Don't start adding features, even cheap ones, unless they've gone through due process.
-- Dave Harris
Your final sentence is just right. In XP, due process means that the customer decides. A wise customer will listen to anyone, even developers.
I choose not to express here my opinions on marketing people ;->. However, the customer role is the place where priorities are set, not in programmers deciding what would be neat and easy to implement. The XP process is that you get stories from the customer (we don't care where the customer gets them), and you estimate how long they will take to implement (i.e. how much they will cost). The customer makes the determination whether the value is worth the cost, setting the priority and order of implementation accordingly. The programmer does not make this determination, or dilute it, by implementing things that aren't asked for. -- Ron Jeffries
I buy what you're saying (remember I like this stuff and am trying to improve my understanding of it) but it does sound like Extreme Projects Require Extreme Customers. Writing stories, deciding what is important and what isn't, deciding which iterations they would like to see which features, is not the normal customer modus operandi in my business (financial software product developed by an independent software house) in my part of the world (London, UK). It really does sound to me that the customer is practicing (or being trained to practice) some of the underlying ethics of YAGNI/XP.
-- Paul
I think Business has natural extremity. They want something, so their priorities fall into focus. If you can't get them to communicate what they want, it is a Red Flag. They just don't want the software badly enough to make it worth working with them. I like Kent's term "Business", because (if I understand it correctly) it covers both the users in an in-house project and marketing/customer focus groups who act as proxies for users in product development. -- mf
Well trained customers - try appending the word "role" where Ron Jeffries has "customer" or "programmer".
The point is to separate "technical difficulty" from "end-user value", and to make sure both are considered. Otherwise, you'll spend time implementing features because they are easy or elegant or whatever, when from a value point of view they should be deferred or not done at all. (You can also get the opposite - salesmen promising their customers features that they know they really want, without checking technical difficulty first. Not good.)
The easiest way to keep them separate is to have them done by different people - and anyway they require different expertise. That doesn't mean the "end-user value" has to be set by the actual customer. It might be a domain expert, or your boss/project leader, or whoever has the deep knowledge of what the customer wants. It can even be the same guy who does the programming as long as he is aware he is filling two roles and has the expertise/customer knowledge. But that case is dangerous. (See Ted Nelson's The Curse Of Xanadu for an example.)
-- Dave Harris
If the customer won't buy it unless it has feature X, whether that feature is useful or not, then you _are_ gonna need it. You Arent Gonna Need It refers to avoiding coding beyond the business requirements. And tick-list features are often business requirements.
And man, oh, man - how quickly those requirements change. Often the marketeers are only slightly less technically naive than their customer base. How often have we seen products that get put out for Beta review and the end users say, "What?!? I had no idea this widget could do that!" Suddenly there are tons of "new" requirements on the product based on the marketing/customer understanding that the dumb box is capable of a whole lot more than it is currently doing. Now, is it not our duty to foresee that? Extreme products which haven't addressed underlying pent-up need are not going to sell.
Isn't the notion of an Extreme Product a contradiction in terms? Except for extensible programming tools, end users have no interest in how the product was developed - what language(s) the programmers used, what debugger they used, what source-code control system they used, or what process they used. All they care about is the end product.
Regarding the fact that marketers sometimes don't know what can easily be programmed, this is an argument for having the programmers talk with the marketers and propose ideas. It's not an argument for spending development time on features that don't make the product more attractive or valuable to the customers.
One other thought: be aware that marketers and customers learn at a certain rate, just like programmers. As I understand XP, it explicitly incorporates learning into the (programming) process. It says, "You learn way faster by getting your hands dirty with real code than by trying to think ahead a whole lot." Just as programmers learn by writing code, customers learn by seeing software in action, and marketers learn by watching customers in action. If the programmers tried to anticipate and prevent every theoretically sub-optimal decision by the customers and marketers, they wouldn't get products into their hands as fast, and everyone would learn more slowly. Your duty as a programmer is not to short-circuit the learning process, it's to deliver software.
-- Ben Kovitz
See original on c2.com 