Re: [xml-dev] Re: XML As Fall Guy

[Thomas Passin <list1@tompassin.net>]

On 11/28/2013 1:46 AM, Stephen Cameron wrote:
> My theory is that the idea of issuing tenders, which is based on
> defining requirements up front, is just plain wrong for complex software
> systems, that are essentially part of the culture of an organisation.
The problem of writing requirements up front is that one often can't 
know all the important aspects of the problem until one gets well into 
trying to solve it.  Same with quoting a project - early on, you can't 
quote with precision unless the job is very similar to others you have 
done.  But a contractor has to know what it's bidding on in good detail, 
so you can't just leave lots of details until later.

> The only solution is to get people with the expertise to do ALL the
> work, including writing a specification if necessary, and to take ALL
> the risk.
And right here is a good example of the confusion many people and 
agencies have, one that often causes no end of difficulties.  There are 
requirements, and there are specifications. And they are not the same. 
Requirements are what the end user/agency needs to accomplish, 
specifications are testable statements of behavior that, if passed, help 
to show that the system will accomplish the requirements.

They are not the same.  The builder can only design and build a system 
to meet a set of specifications - because they are what can be tested. 
The requirements - needs of the customer - ideally will mesh with the 
specifications (or the other way around).

Let's say, for example, that you are the buyer of a car to be developed, 
and one of your requirements is that the car has to be able to transport 
a family of four at least 400 miles between refueling stops.  Fine.  The 
vendor will have to say "well, a family of four, we will take that to 
mean two adults weighing an average of 160 lb apiece, and two teenage 
children, height 5 ft 6 inches, weight 130 lb (sorry, metric users!). 
"transport" we will take to mean drive at an average speed of 55.

Good.  Off we go to design and prototype.  We estimate the weight of the 
vehicle, then we can estimate the amount of fuel, and by iteration we 
converge on a workable design.

But now the customer comes back and says that the adult weights must be 
170 lb, the teens will need more room, and oh, yes, the customer forgot 
about baggage.

OK, fine, maybe the changes can be accommodated, maybe they can't.  But 
the vendor can't now accept all the risk for failure.  The vendor quoted 
the job, but now the basis for the original quoted design has been 
changed.  Maybe the changes make for an overall system that's no longer 
feasible.  Maybe a complete redesign is called for.  Now there are lots 
of risks, and the vendor can't know how much to charge to account for them.

Though this is a very simplified example, it's realistic in the sense 
that this kind of change goes on all the time, and ordinary contracting 
practices just aren't up to handling it.  "The" government (whichever 
one you want to talk about) can be pretty bad about it, but not just 
government buyers.