PEN-L
mailing list archive
[ Other Periods
| Other mailing lists
| Search
]
Date:
[ Previous
| Next
]
Thread:
[ Previous
| Next
]
Index:
[ Author
| Date
| Thread
]
re: Analyzing Technologies
On Fri, December 26, 1997 at 07:54:25 (-0800) James Devine writes:
>...
>BTW, there are efforts to deskill programming, by having the code-writers
>focus on only modules or "objects" rather than the whole program. I don't
>know how successful these efforts are.
One of the standard ways of deskilling is pretty straightforward. You
separate coders into "designers" and "implementers". The smart guys
build "interfaces" --- that is, they specify *behavior* of components
--- and "monkeys" code the bowels of the system to satisfy the design
requirements.
Of course, most programming is itself constrained even on the
interface side of things --- management decrees they want a system to
support X users, at Y transactions per seconds, and it must do this
and that. This is passed down to the interface designers, eventually
ending up in the laps of the implementers. Despite my disdain for
Scott Adams, he does often accurately capture this sometimes idiotic
relationship between management and software engineers; but his view
is actually becoming rapidly obsolete: just as in the past, management
is becoming staffed with more and more "co-opted" programmers who know
the limitations of technology and are able to spec out things
reasonably well themselves.
However, this can get rather costly, since communicating design
requirements can be a bureaucratic nightmare. You get much better
code when the same programmer works on both (all three?) sides of the
fence. This is an example of how the stupidity of capitalism drives
systems away from optimal functioning in order to impose control.
One explicit measure of this is that code written by the FSF (Free
Software Foundation) tends to be vastly superior to commercial stuff
--- faster, more flexible, and fewer bugs. So much for the
"efficiency" of market-driven relations. I actually think that more
attention should be payed to the cooperative successes of the FSF
(and, many other non-corporate software projects).
Bill
[ Other Periods
| Other mailing lists
| Search
]