Design documents versus prototypes

I'm frequently given tasks by a huge corporate customer with a
heterogenous IT system and more Business Analysts and consultants that
you could shake a stick at (even if you were particularly adept at
stick-shaking).

At a project review today which covered multiple projects, the
customer acknowledged that I had delivered the required code in less
time than the already very tight time-frame, and that the cost was under
what they had budgeted for.

Then I got a bollocking for not producing design documents so that the
BAs and consultants could see what they were going to get.

The only thing that I could think of saying in my defense was 'I did
give you the design documents, but instead of being written in Word,
they were written in Delphi, they worked, and showed you precisely what
you were going to get'.

I had taken the requirements document and used the RAD power of Delphi
to show exactly how the system would work in less time than it would
have taken me to come up with a bunch of words that conveyed much less
information.

Since the data access layer didn't exist when I created the prototype,
I used things like:

procedure TMyForm.OnBarcode(sender : TObject; const Barcode : string)
begin
{$IFDEF FAKE}
// code that responds with some hard-coded values
// and shows what should happen
{$ELSE}
// no code here, but this is where I'll write the real stuff
{$ENDIF}
end;

....and put some real logic into the FAKE part so that all eventualities
could be tested as long as they stuck to the hard-coded barcodes.

I know that I'll never win the battle of words versus work. The
Project Manager even said "This is the same problem we've had with you
for the last 14 years, but you always deliver on time (or before time)
and on or under budget", so she's not going to win either.

What amazes me is that few corporates ever take advantage of the
incredible power that Delphi provides in being able to produce working
prototypes in a very short time.

I also got a bollocking for refusing to commit to a delivery date. As
I said, this is an heterogenous system, and when I built the prototype,
the data access layer didn't exist and was provided by another party. I
was happy to commit to "3 days after the data is available, you can have
your Delphi system", but project managers often don't see that as a
commitment.

Some of the parts of the system were written in Java, others in COBOL,
and the rest is Delphi. The Java part slipped under the radar 'coz none
of the BAs actually understand what it does, and it seems that for COBOL
stuff you really need to write documents specifying what is going on (or
is planned) while the Delphi stuff just works.

Don't get me wrong: if there is a need to write database design
documents to illustrate how the data relationships are going to work,
then I'm your man. But if the proof in the pudding is whether or not
the solution is going to fulfill the requirements, then I reckon that a
prototype wins hands down every time.

And it seems that amongst all of the tools available to all of the
people that work with these projects, only Delphi is able to produce
working prototypes within the sort of timeframes that we are given.

The other thing that I love about Delphi is that there's not too much
trouble in turning a prototype into a working system. Yeah, we can mess
about with the prototype till the cows come home, but when the customer
finally agrees that the prototype does what is required, there's very
little work left to do.

What's your experience?

Scout



.

Relevant Pages

  • Re: Design documents versus prototypes
    ... Then I got a bollocking for not producing design documents so that ... Delphi to show exactly how the system would work in less time than it ... Since the data access layer didn't exist when I created the ... prototype, the data access layer didn't exist and was provided by ...
    (borland.public.delphi.non-technical)
  • Re: The early years
    ... I bought the upgrade to D6 after a Borland ... The comment of Borland customer ... madExcept - and it's a shame that Delphi does not have something similar. ... Same for FastMM4 debug features, it could be in Delphi since version 5. ...
    (borland.public.delphi.non-technical)
  • Re: Design documents versus prototypes
    ... Then I got a bollocking for not producing design documents so that the ... I had taken the requirements document and used the RAD power of Delphi ... I said, this is an heterogenous system, and when I built the prototype, ...
    (borland.public.delphi.non-technical)
  • Re: .NET or Win32 - Re survey by James David
    ... loyalty and customer base increases each year for it. ... > believing Delphi was being abandoned and is dead-ended in W32, ... Far more than half already think that without delivery of a D7SP in over ... Again, just my opinion. ...
    (borland.public.delphi.non-technical)
  • Re: Open Letter to Borland: Declaration of Delphi Dependence--Original Text With Paragraph Breaks
    ... What exclusive features will rescue Delphi from mere ... From a dynamic place with a huge success to a small ... The customer base for software eroded faster than they ... the OS nor of Delphi offer me more productivity. ...
    (borland.public.delphi.non-technical)