any software requiring maintenance "matters" to the person who relies on it to work, no?

Thanks for the comment, will.

If the people paying the bills refuse to hire someone competent to maintain the software, I doubt very much it really matters to them.

Harrumph. Do you consider it baby-talk to spell out SICP? I had no idea it was a book until, with great effort and inconvenience, I clicked the link.

And now I retire to rest and recover.

Oops! I've expanded the acronym and linked to the book online, Carla. Thanks for keeping me coherent.

Thank you, I was almost beyond recovery. ;)

Seriously, it's wonderful that the book is available online for free. Thanks for the link.

The title attribute is handy for acronyms.

If you want to use a link, you can make SICP a link but add a title attribute. Or wrap SICP in acronym tags and again add a title attribute.

I haven't read the book, but I've begun watching the videos. Here's a link: http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

I hate to disagree with you on your statement "Perhaps software development may finally begin to improve if we can kill the idea that ignorant and inexperienced novices ought to be able to maintain code that matters", so I won't :-) Seriously, that's a little harsher than I would have put it, but the truth remains. The quality of code which is written is directly proportional to the skill of the person writing the code. You can't expect toolset XYZ to magically overcome shortcomings in someone writing code. Maybe that's a mis-understanding of tools. Good tools can help coders write code faster. There are even tools which I wouldn't necessarily consider "good" which can still help coders write code faster. The problem is that the tools can simply allow bad coders to write bad code faster.

Jeremy, I didn't have tools in mind. Instead, I meant that deliberately avoiding the idioms of a language or library or platform because a novice might not understand them is a huge, and largely unaddressed, technical risk.

It isn't just lack of understanding that leads programmers to ignore the idioms of a language or even the built-in functions included in the standard libraries. I have seen programmers write their own implementation simply because they are so tied up in the NIH (not invented here) mentality.

chromatic,

Gotcha. But I would say that there's a line between writing code which takes advantage of powerful idioms of a language and writing code which is obscure. I'm sure this isn't exactly what you're talking about, but it deserves saying. I've simplified code for myself (i.e. which no-one else would be maintaining) so that I would have less problems understanding it when looking at it later. I consider re-writing for the sake of clarity and maintainability a good idea. However, to intentionally avoid something in Python like list comprehensions, map and lambda (when appropriate!), or "enumemrate" (none of which are complex at all, but you get the drift) because some new or inexperienced programmer may not understand them is a problem. If you're using a language, you need to explore the language so that you're aware of the sometimes less-used powerful features they offer. "Shielding" noobs from the fullness of a language is actually a disservice to them. Dumbing down your code base is about as useful as dumbing down a teaching curriculum. It's really just no good for anyone.

Frank,

Good point about NIH. I've heard, but never experienced first-hand, horror stories about people re-writing huge sections of code either because it wasn't written here, or because it wasn't written here and they could not allow themselves to just accept the slight differences between how the authors wrote it and how they would have written it themselves. I think this is on the other end of the continuum from what chromatic is mentioning here and is just as serious of a problem.

Jeremy, exactly. Sometimes clarity means using complex idioms. Though it takes more work to understand higher-level abstractions, the clarity and power and brevity you get from combining well-designed abstractions makes it easier to understand the purpose of a local section of code as a whole than if you only used very simple operations.

For example, I can write a while loop in assembly language such that anyone who understands the JNE and INC operations will understand it. However, using only that technique for all flow control--because the individual pieces are so easy to understand--is silly.

When writing code for others to read and maintain, there's a difference between:

Writing code the way you think they would write it, and,

Writing code that they could study, learn from, understand, and be able to modify.

The latter assumes that the person coming after you may not have your level of experience, but that they are competent and motivated to learn.

The quote referred to appears in the preface of the first edition, (mine has a note dating it to 20-oct-1985), on page xv. The authors address chromatic's concern on p.2 of that edition:

"A master software engineer has the ability to organize programs
so that he can be reasonably sure his processes will perform the
tasks intended. He can visualize the behavior of his system in
advance. He knows how to structure his programs so that unanticipated problems do not lead to catastrophic consequences, and when problems arise, he can debug his programs. Well-designed
computational systems, like well-designed automobiles or nuclear
reactors, are designed in a modular manner, so that the parts can
be constructed, replaced, and debugged separately."

I agree with chromatic that the book takes some work to get
through, but doing so will do for the programmer what working
through all 3 of the Feynman Lectures on Physics will do for the
physicist. I have not yet encountered a better book on the
real work of programming, which is deciding where and how to
make the abstractions that allow our limited human brains to
successfully construct operational large-scale systems that do
the right thing almost all the time.