Of course, hacking is in fact #5.
On 4/15/20, 1:34 PM, "Friam on behalf of Prof David West"
<[email protected] on behalf of [email protected]> wrote:
True, it does advance an argument for a rational process (i.e. guidelines).
But it also states that such a process can never be other than an idealization
(as you note).
There could be value in after-the-fact faking of a rational process, if the
fake was used to inform and "improve" the process such that it became a closer
approximation to the ideal.
If you establish a continuum
1. hacking ---> 2. ad hoc heuristics / best practices ----> 3. informed
heuristics / best practices ---> 4. rational process
then my interpretation of the paper seemed to suggest that faking the
rational process could lead to iterative improvement and move the profession to
stage three of the continuum.
But, everything I have read about Parnas, and especially when he was in
charge of the SDI, seemed to be to be very pessimistic about the
profession/practice ever getting beyond stage 2. His resignation letter from
the SDI project stated that such a project mandated the use of something much
closer to a rational process than was achievable in the foreseeable future.
I don't know if CPSR has any archives of the papers / communications from
the early years when Parnas continued this argument and generalized it to most
"mission critical" software. I read them at the time but do not have them in my
files.
I don't think I am arguing against your point, but I am highly skeptical
and deeply cynical about its being realized.
We have had very different careers in software development. Mine started in
1968 as a COBOL and Burroughs Assembler programmer and reached CIO before I
returned to graduate school. All of that experience was in corporate or
government software development organizations. Ninety-five percent of the
students I taught at St. Thomas had professional experience in the same kind of
organization and they shared their experiences and observations with me. There
were a few students, and I had a few consulting encounters, with development
processes that were reasonably formal — at Medtronic, IBM, CDC, and Cray for
example.
From that experience I concluded that formal, scientific, engineering
approaches were nearly useless for developing the kind of software
business/governmental organizations and teams were charged with. Clearly, there
is some software that is amenable to and enhanced by engineering approaches. It
is a matter of the nature of the underlying problem domain and the degree to
which that domain is itself substantially a formal system.
The 2006 DoD funded Ultra-Large Scale Systems Study Report — Linda
Northrop, lead, SEI at Carnegie-Mellon — confirmed my cynicism when they noted
that software engineering was not and could not be the means for developing
software for a complex domain like Ultra-large-scale-complex-adaptive-systems.
davew
On Wed, Apr 15, 2020, at 12:24 PM, uǝlƃ ☣ wrote:
> That paper:
>
> https://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf
>
> argues *for* guidelines for software development. So, it validates my
> point in the most direct sense. It *also* argues against inferring from
> Nick's idea that there might be such a thing as Laws of Software
> Development Procedure, in that the ideal is never met. So, it validates
> my point about heuristics and best practices from that perspective, too.
>
> Did you intend to say that this paper is contrary to Nick's point? Or
> contrary to my point?
>
> On 4/15/20 8:02 AM, Prof David West wrote:
> > A contrarian position: David Parnas, "The Rational Design Process: How
and Why to Fake It."
>
> > On Wed, Apr 15, 2020, at 8:43 AM, uǝlƃ ☣ wrote:
> >> No guidelines for how much to ship to any given hospital. No
guidelines
> >> on dosage. No guidelines. We don't build bridges that way. We don't
> >> write software that way. We don't cook food that way. Etc. Why should
> >> we "treat" patients that way?
>
>
> --
> ☣ uǝlƃ
>
> .-. .- -. -.. --- -- -..-. -.. --- - ... -..-. .- -. -.. -..-. -.. .-
> ... .... . ...
> FRIAM Applied Complexity Group listserv
> Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam
> unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
> archives: http://friam.471366.n2.nabble.com/
> FRIAM-COMIC http://friam-comic.blogspot.com/
>
.-. .- -. -.. --- -- -..-. -.. --- - ... -..-. .- -. -.. -..-. -.. .- ...
.... . ...
FRIAM Applied Complexity Group listserv
Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam
unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
archives: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/
.-. .- -. -.. --- -- -..-. -.. --- - ... -..-. .- -. -.. -..-. -.. .- ... ....
. ...
FRIAM Applied Complexity Group listserv
Zoom Fridays 9:30a-12p Mtn GMT-6 bit.ly/virtualfriam
unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
archives: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/
