Re: signature like constructions

[aek@vib.usr.pu.ru (Alexander Kopilovitch)]

Robert I. Eachus wrote:

> One of my 
> favorite examples was a project actually written in Ada, but that is 
> almost a detail.  The original schedule called for a three year 
> development cycle, in C and assembler.  Two years in, that group 
> admitted total failure. I'll get back to why in a minute.
>
> Another group volunteered to take over the project and do it in 11 
> months to meet the original schedule--if they could use Ada and modern 
> software development methods.  They got the go ahead on a plan which 
> called for six months of requirements analysis and design, two months of 
> detailed design, two months of coding and one of testing.  At the end of 
> detailed design, eight months in, they decided that a significant 
> portion of the original design need to be scrapped and redone.  They 
> finished coding a week behind schedule, but completed the formal testing 
> in two days--the test suite has been developed as part of the entire 
> process, and coded by a separate test group within the project.
>
> The manager in charge called it management by heart attack.  It is one 
> thing to logically accept that starting coding too early will be a 
> disaster, but to finally start coding in the ninth month of an eleven 
> month project can stress a manager out.  But it works.  In fact the rest 
> of the operating system that it was part of slipped three  months, so 
> that all of the features that had been postponed to version two were in 
> there when it released.  But they actually formally did keep those 
> additions as a second version in the configuration management system, 
> and tell marketing that they would get it all when release two was ready 
> but nothing before then. That allowed the first version kept bug free 
> during beta test under version control so they didn't get involved in 
> fighting fires.

Just curious about the difference or similarity between the cultures: from my
former Soviet experience (I have seen somehow similar cases, although possibly
of lesser scale) I can guess that that too successful group was rewarded,
praised and then dissolved for they could never repeat such unnatural
performances any more. Was the outcome the same (or similar) in the case?
Or this group was permitted to exist for years after that performance?


> During the first day the marketing team realized that it would be nice 
> if there was a standard option just for backing out of transactions, as 
> well as the key that took you to the top of the current menu hierarchy. 
>   This wasn't considered a show stopper, but marketing wanted an 
> estimate on the cost of adding the feature.  The review finished early 
> on the second day, and they were going over action items.  The manager 
> of the project was able to tell them that the changes had been made, a 
> new version compiled overnight, and was now on its way to the 
> Distribution and Test group for their blessing.  In the meantime, it had 
> been installed on one of the test machines if they wanted to check it out.
>
> You might think that the developers had anticipated this change request 
> and had it all designed in.  But that wasn't how it worked.  Since the 
> main requirement for the subsystem was to present a consistent interface 
> to the user, the design of the system was a rule based engine that 
> generated the screens.  The change to the code was three lines, because 
> the system did model the problem space.

Note, though, that relying upon specific tools - such as problem-oriented
languages (SNOBOL, APL, COBOL, Fortran, Prolog etc.) or libraries is actually
a "poor man solution" for the desire to operate in the problem space. I mean
that if you can't obtain (or even "develop") more or less precise and stable
requirements, and even worse, you can't go deep into the real problem (all that
is common case), and therefore you can't develop proper custom representation
of the problem space, the best strategy may be to rely upon the tools already
widely used for that class of problems. With this strategy you have at least
good chance for operating not too far from the proper problem space (because
the tools will bring you there).


> > You have seen the miracles being used more that in one or two cases -- so you
> > are lucky. I think that most of us feel that the miracles, if happen, will be
> > most probably betrayed. That's why "Adding an understanding of ISAs and machine
> > architecture to that is very rare" indeed.
>
> And I have also seen disasters where this sort of discipline was 
> necessary due to the scope of the project, but was not put in place.  In 
> fact I may finally get around to publishing that paper.  (Basically how 
> to tell when the project is dead beyond all hope of recovery from 
> analyzing the reports in the bug tracking system.  The earlier you can 
> determine that a project will fail, the less money you waste.)

Well, if you actually publish that paper then, perhaps, it will be rare case
of a text about programming for which I believe that Russian translation is
desirable -;)



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia