There is an ever growing number of <noun>-driven processes being touted, i.e. Use-case driven, Test-driven.

Since most software is developed for a customer and not the developer implementing the software, shouldn't software development be driven by value delivered to the customer? I would define value as useful and usable functionality (or business value) delivered to the customer. This concept seems to be conspicuously absent from many of the processes or methodologies I read about, both on this Wiki and elsewhere.

''On the contrary, this kind of approach is all over this wiki. PlanningGame. UserStories. OnSiteCustomer. ReleasePlan. YAGNI. ExtremeProgramming is about delivering what the customer has asked for in a way that works now, not what the developers think might be needed later.''

If you write an elegant test-driven module that works as designed and has nothing to do with the customer needs, where is the value?

Another point - spending time correcting minor defects may result in less value delivered than implementing a much needed feature requested as a change. I'm not saying you should strive to produce defective code, but if you take value out of the equation you risk moving farther towards abstract and academic ideals that run contrary to customer need. Shouldn't development time be focused on delivering the most value possible to the customer?

This seems like an obvious idea to me, but I rarely see any reference to actual value delivered. Perhaps this is a contributing factor to the number of failed projects. Customers don't pay for process, they pay for value. After all, customers don't use test cases or UnifiedModelingLanguage, they use the software. Process and methodologies and standards all make sense - to the extent that they allow us to deliver more value to the customer.

I'm interested in hearing your thoughts on this.

--DavidBeardsley

''David - test-driven programming exists inside the engineering team, out of sight of the customer.  It ensures that the stuff that gets delivered is always at a very high level of quality.  What the programmers are testing and building is completely up to the customer, which is quickly evident once one has a basic introduction to ExtremeProgramming.  see ExtremeProgrammingRoadmap.  IOW we are all in violent agreement with you.''

CustomerTest''''''s are the requirements so they are visible to the customers at all times, ProgrammerTest''''''s are usually out of the customer's sight.

----
see TestDrivenDevelopment, TestDrivenAnalysisAndDesign