[plt-scheme] Perplexed Programmers

Did I miss something?

Does HtDS mean "How to Design Systems" ?

If it does, this thread shows that there is a need to extend the HtDP
approach to the design of real systems, where the initial specs are
always vague and the knowledge needed to clarify them often distributed
among a community of people in a complicated way.

So when does the book come out? Can any "been there, seen that,
cancelled that project" veterans give any help to the process?

CS

Matthias Felleisen wrote:
>
> My answer/question was a bit flip but it came straight from the heart
> of someone who has taught freshmen a dozen times since 1992. The
> "product" I get to see is so under-educated that I have to think that
> the many many more billions that parents and taxpayers spend on public
> schools are even more wasted than the $95M that the LA ISD spent for a
> partially correct program.
>
> In addition, I believe that the education of programmers is seriously
> flawed, starting with how-to-code-in-24-minutes, on to high school CS
> education, college and MS cash-cow programs. As my sons' piano and
> saxophone teachers used to say, the first year sets the tone. The
> habits that you pick up there dominate your internalization. (Some of)
> those of us who have overcome this tone-setting experience are on this
> list. We tend to be highly introspective people.
>
> For specific failures like that, I tend to believe that both
> programmers and managers are at fault:
>
> * Thesis: Code has two users. The first are the ones who interact with
> the program after deployment. The second are the programmers who look
> at the code after it was created, read it, and modify it. This happens
> during development as well as maintenance. I conjecture that the
> concerns for the two communities are related. [
>
> * Managers should represent both users. They are the feedback element
> during the development cycle. They barely succeed with representing
> the first group and are never educated enough to represent the second
> one. Even though business programs teach discount and opportunity cost
> and everything, managers just don't understand this point when applied
> to software.
>
> * Result: Code is considered successful if it kind of works for the
> interacting community and is roughly on time. XP succeeds [more than
> regular programming] because it replaces Managers with real Customers
> during the development cycle and always focuses on feature
> interaction. They thus get better trained programmers, just like shops
> in the spirit of JaneStreet.
>
> * Programmers should understand the issues, even if they can't do all
> the business evaluations. If they see things going wrong, they should
> push back. They don't.
>
> * The people who could see it all are those who train programmers and
> have a modicum of business sense. Or at least those who set the
> curricula. This is where I lay the largest blame but it's a long-term
> problem and could be seen if enough push-back from enlightened
> programmers and managers came in.
>
> [This whole thesis is the premise of my HtDP, HtDC, and HtDS; and the
> last bullet is perhaps the reason why this is the case.]
>
> -- Matthias
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.racket-lang.org/users/archive/attachments/20070827/5da06795/attachment.sig>