🚀 go-pugleaf

From rcd@ico.ISC.COM (Dick Dunn):
>> >>    ...We're here to engineer products on time, under budget,
>> >>    and with as much quality as we can get within those two constraints.
>> > ...It's particularly
>> > sad to see "quality" a poor third to the other two.
>>    If the product does not meet the minimal standards of acceptability,
>>    then it is not complete.  "On time", etc., refers to the product
>>    being completed in accordance with the relevant quality requirements.
> 
% It is entirely possible to construct software which meets all such require-
% ments, but which is poorly conceived or implemented.  Examples abound.  I
% know of no way to specify software requirements such as "must be able to
% survive the next five years of changes, to meet new needs, hacked in by
% bored second-string maintenance programmers..."  But that's often what
% quality software needs.  [...] My personal peeve here is that I spend 
% far too much of my time reworking under-engineered hacks back into 
% decent code that can survive.  So I see an extreme focus on 
% budget/schedule as needlessly increasing the amount of such work I
% have to do.

    This depends upon whether the product is implemented by hackers
    or by professionals.  A professional will meet cost and schedule
    constraints by using CASE tools, advanced programming languages,
    and so on, using overtime as the last resort.  A professional
    knows that developing modular, readable software not only helps
    make the software maintainable, but also reduces the probability
    that the product will be delayed due to errors and reduces the time
    that will be required to correct errors if they are discovered,
    thereby enhancing the probability of meeting scheduling constraints.

    Dick's particular environment is one in which operating system 
    software is being developed in C, a double whammy as far as a 
    well-established tradition of hacking is concerned.  In such an
    environment, great efforts must be taken on the part of management
    to ensure the existence of a proper software engineering orientation.
    

    Bill Wolfe, wtwolfe@hubcap.clemson.edu