Subj : Re: Software Job Market Myths To : comp.programming,comp.software-eng From : David Lightstone Date : Mon Jul 18 2005 12:55 am "topmind" wrote in message news:1121625846.513906.63100@o13g2000cwo.googlegroups.com... > > > David Lightstone wrote: >> "Phlip" wrote in message >> news:aFvCe.65$IG2.40@newssvr33.news.prodigy.com... >> > pete wrote: >> > >> >> All that you need to be a customer, is money. >> >> You don't have know anything. >> > >> > True. So to grow a successful software project, you need Someone >> > capable >> > of >> > specifying its features. The better they know the target domain, the >> > better >> > they can specify. >> > >> >> Sometimes the answer to "What do you want?" is "What do you have?". >> >> As a project progresses, the customer becomes >> >> aware of the programmers capabilities >> >> and then you have specification creep. >> > >> > No. Then the customer steers the project towards business goals. >> >> >> Am I quoting you incorrectly " The bottleneck is often the user/customer. >> They often don't really know what they want and/or how to describe it >> with >> words." >> >> How can you steer when you don't know what you want? > > It just means that you *have to* steer as you learn more > of what you want and have to change directions. If you > never change directions, you don't need a steering wheel. Frankly the metaphor steering is a gross misrepresentation. Steer is what you try to do in a tactical situation, there is little opportunity to "learn more as you go" under those circumstances. You either act and react correctly (no learning needed), or you don't. Figuring out the overnight stops (increments) in a trip between New York,NY and Phoenix, AZ is somewhat different. Phlip's contension, that the customer doesn't know probably corresponds more so to increment definition, than making tactical choice between no brain in the loop steering type decisions > >> >> > >> > Specification creep is _good_; it's the result of learning. >> >> Without doubt, but in the context of software development learning what >> you >> REALLY want to do after you have done it once just isn't part of the >> production drill for which certain techniques > > Managers want predictability, but often this is just not possible, at > least not without putting annoying limits in place. How does this relate to feature creep? (unless by limits you mean limits to the additions that will be accepted) > > Predictable, easy-to-specify projects are going overseas, leaving the > messy ones to those of us left. Thus, the chaos (or "organic progress") > will only increase for those of us in the "expensive" world. This is a valid and highly meaninful observation. I would guess that WEB site development corresponds to your "easy-to-specify", safety critical the "expensive" world > >> >> > >> > Implementing features in order of business priority increases the odds >> > that >> > the team has something useful soon. This increases understanding what >> > the >> > next features should be. >> >> Without doubt, but that assumes the customer knows what they want. You >> have >> asserted the invalidity of that assumption. Pick one assumption and run >> with it, don't waste our time with doubletalk > > There are usually things you know you want, and things you aren't quite > sure of. Getting the ones you know you want can help clarify the > fuzzier ones. Yes, I am more than aware of the distinction between problem solving and the proverbial no-brainer > For example, in an on-line sales system you know you want > to process customer transactions and distribute what they ordered. > However, how to go about promotions and marketing research is not > always so clear. > > Either way, if you are going to go about it in an organic way, focusing > on even a tentative priority list is better than no list. > > -T- > .