Many development processes emphasize the role of the customer in product development, WorryDrivenDevelopment is no exception. However, the customer in a WorryDrivenDevelopment process assumes a different role. Other processes focus on having the customer as a member of the design team; providing the team with requirements and UserStories and the like.  

This is an AntiPattern. It is well known that TheCustomersAreIdiots, who if allowed to be involved in the design will loudly insist that IwantaPony, and will demonstrate a clear lack of sympathy for the limited resources available to the project. However, there is one area in which customers are quite useful - testing.

* I like this phrasing; shall I attribute it to Anon when quoting, or is there a better attribution? ''Tis ScottJohnson again - now posting from home''

Simply ship software (labelled as "complete") to the customer. The defect reports from the field will start to roll in, as customers discover all sorts of defects uncovered by the design team. This practices has several key advantages:

* Programmers and SWQA staff, for some reason, insist on being paid - even overseas workers command premium salaries. The customer, on the other hand, not only will perform QA for free, ''he will pay you for the privilege''.
* This is one way the fact TheCustomersAreIdiots will work for you. As idiots, the customers will find ways to break your product that your design and QA teams (who, being intelligent individuals, will know to avoid) will fail to find.
* This practice also provides additional revenue opportunities, through the selling of maintenance releases. Simply take the reported bugs, divide them up among a series of maintenance releases, fix some in each one, and charge the customer to upgrade. If the other KeyProcessArea''''''s are followed; the number of defects fixed in each such upgrade will be offset by new defect introduced by the attempts to repair the existing defects. (But make sure you RemoveTest; otherwise you might discover these defects yourself, and thus deprive yourself of the revenue opportunity the defect creates).
* The issuance of maintenance releases also provides numerous opportunities to introduce VendorLockIn, by coupling the bug-fixes to some new feature or architecture change which breaks a competing product (or forces the upgrade of some other product which you offer, in order to maintain compatibility). This strategy has worked for several prominent software companies.

Some methodologies advocate early release of pre-production code to customers to implement CustomerQa; this is often called BetaTesting. This, too, is an AntiPattern that should be avoided. For one thing, the customer may expect the discovered defects to be repaired before the "final" release is shipped. For another, in most cases this means foregoing a revenue opportunity, as many customers are reluctant to pay money for beta code. Unless, of course, it is labelled 1.0.

----
This is awesome.

However, I'm '''worried''' that there is not enough worrying involved here. And, is this actually accomplishing real work? WorryDrivenDevelopment avoids doing real work :)

Although, this practice does encourage the developers to avoid actually finishing there work. This does fit the WorryDrivenDevelopment definition somewhat :) Hmm, maybe we need an EndlessMeeting to discuss this...

Maybe this practice supports WorryDrivenDevelopment, but is really part of a much broader IdiotProofProcess, yet to be named, that WorryDrivenDevelopment is also a part of?

Thanks for a very enjoyable break in the day. Cheers, -- JasonNocks

----
CategoryHumor