Re: Re: OT - poor word choice re: Managing Extreme Programming

Bryce Kampjes <[email protected]> Wed, 22 Jan 2003 14:00:35 +0000
Newsgroups gmane.comp.programming.extreme-programming.adoption
Message-ID <[email protected]>
Ron Jeffries writes:
 > On Tuesday, January 21, 2003, at 1:25:55 PM, Alleman, Glen B. wrote:
 > 
 > > We are completing a transition to our parent company. The president of
 > > our group is a former AT&T and Lucent president. For those uninitiated
 > > developers his comments at the kick were eye opening. "we (the new firm)
 > > need technical skills, this is critical to the success of the
 > > firm....but more importantly we need customers...customers come from
 > > sale guys..."  This point of view is much different than the previous
 > > firm's professional engineering services view of business.
 > 
 > Customers do in fact come from sales people. I believe that good sales
 > people are critical to business success.
 > 
 > However, if the business is to endure, even the best sales guys cannot be
 > selling crap. As you say below, both sales and product are critically
 > important.

The term that the sales guys I know use is referencable
customers. With good responsive customer communication we
could sell crap and turn it into a big business
success. Business quality is a different thing to technical
quality.  Good customer communication from the development
teams builds referencable customer relationships. 
Referencable customers are needed by the sales and marketing 
guys to build market share.

I'd argue that TDD produces quality much higher than business
needs for good business reasons. The quality allows us to go
fast and to be responsive which provides large business
benefits. Producing higher quality software can be cheaper
because the quality speeds up development. Test first has an
initial slowdown as we learn how to test our software but
soon starts paying for itself. TDD provides support for short
cycle times which make communication easier.

I have personally seen good software sink because it wasn't
supported into production properly and very rushed software
succeed. The crap software that succeeded was the next
version of the good software that sank. I was a member of
both development teams. The only difference was the second
version was done under hard business time constraints and we,
the developers, directly supported the customers. The
customers trusted the crap software because to them it was
more reliable.

Bryce

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/