Bob La Quey wrote:
Of course you do not have a customer who knows what they want.
That is one reason why definition is hard and requires a lot
of face to face. I must say I have almost never had a
customer who knew what they wanted.
Which means writing it down in advance and then saying "is this what you
want?" generally doesn't work very well.
(b) you can figure out what the customer wants,
If you cannot then you really should _not_ be doing the job.
Worse I would say you are failing. Now, admittedly many projects
and many consultants fail at this point.
Yep. Sometimes the customer knows what they want but are unable to
express it. That's what I was trying to say. So you show them various
versions and zero in on what they actually think they want.
(c) the requirements don't change in the time it takes to write it,
Then you are taking too long to write them.
No, the "it" there referred to the code, not the specs.
and never even met the customer
This is an advantage. It forces you, the system definer,
to do your job. Why must the implementer meet the customer?
I worked for a decade as an outsourcer for a guy who was
contracted to a Norwegian oil company. I _never_ met the
customer, but David K. Walker, could tell me what to
implement. Now I will admit that DKW is good. But dammit,
that is my point. You need to be very good to do a decent
job of system architecture and definition.
So you're saying define everything so exactly that no misunderstandings
can occur and no misinterpretations are possible and nothing at all
needs to be assumed.
Sure, maybe, but it's probably cheaper not to outsource in that case.
(e) that you convince the outsourcees that
they should do what you need rather than what's easiest and most
profitable for them,
The same exact problem lies with any organization that contracts to
have another organization develop software for them.
Exactly, yes.
and (f) you have a way of telling that what you got
back is what you asked for, and
(g) you can tell before you start which
outsourcing group will actually be able to accomplish what you're paying
them for,
Clearly you have no clue how to manage a software project.
Uh huh. And you've obviously never worked on something totally new
where the customers *cannot* know what they want in advance.[*]
Understand that I'm talking about your premise, which is "1 - create
spec, 2 - throw over wall to implementers, 3 - take back results and use."
With more and tighter cycles, this might work, of course.
By the
time you can clearly write unambiguous specs and have an inexpensive way
of ensuring that the result meets those specs and is flexible enough to
meet your future needs, you have reduced the problem to something you
might as well just finish yourself - you've already done 90% of the work.
This depends on the project. I use to agree with you. I no
longer do. For small projects it is true. For larger projects,
where the architecture is critical, I think you are wrong and
that your approach will not work.
What's the "my approach" that you think isn't working? It's kind of
funny, because I didn't say what my approach is, and here you're telling
me it's wrong.
An alternative approach that some say is the only way that
ever works is to start with a small project then when that
is successful to flesh it out. I always want to see what I
call a "tall thin man", a prototype that touches all of the
bases with as many stubs as necessary as early as possible.
Yep. And then as you flesh it out, you find there are dozens of
interfaces and functionalities and failures-of-underlying-support that
were not and could not be considered.
The "tall thin man" encapsulates the architecture but will
not have much functionality. I literally consider this the
most important part of the spec.
Yeah, it's a good part of it.
Maybe I've just never worked on a project the right size to be
outsourced. I've done medium-scale things, and dozen-person things, and
one-two-three person things, but never something like an OS from scratch.
[*] Not that I believe this is true, but I have as much reason for
saying it as you have of impuning my skills.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
