More on this book
Community
Kindle Notes & Highlights
Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. “Somebody finds the problem,” he says, “and somebody else understands it. And I’ll go on record as saying that finding it is the bigger challenge.”
Linus’s Law, I think, lies the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena — or, at least, that they turn shallow pretty quickly when exposed to a thousand
...more
Brooks, Chapter 9: “Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.” Allowing for thirty years of terminological/cultural shift, it’s the same point.
you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. One interesting measure of fetchmail’s success is the sheer size of the project beta list, fetchmail-friends.
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
Traditionally programmers have tended to favor control syntaxes that are very precise and compact and have no redundancy at all. This is a cultural legacy from when computing resources were expensive, so parsing stages had to be as cheap and simple as possible. English, with about 50% redundancy, looked like a very inappropriate model then. This is not my reason for normally avoiding English-like syntaxes; I mention it here only to demolish it. With cheap cycles and core, terseness should not be an end in itself. Nowadays it’s more important for a language to be convenient for humans than to
...more
security system is only as secure as its secret. Beware of pseudo-secrets.
be able to present is a plausible promise.
But the problem with being clever and original in software design is that it gets to be a habit — you start reflexively making things cute and complicated when you should be keeping them robust and simple. I have had projects crash on me because I made this mistake, but I managed to avoid this with fetchmail.
The Psychology of Computer Programming supplied
One of the best-known folk theorems of software engineering is that 60% to 75% of conventional software projects either are never completed or are rejected by their intended users. If that range is anywhere near true (and I’ve never met a manager of any experience who disputes it) then more projects than not are being aimed at goals that are either (a) not realistically attainable, or (b) just plain wrong.
It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically
To pragmatists the GPL is important as a tool, rather than as an end in itself. Its main value is not as a weapon against “hoarding”, but as a tool for encouraging software sharing and the growth of bazaar-mode development communities. The
Most people have implicit mental models for both of the above, and how they interact with each other. Government, the military, and organized crime (for example) are command hierarchies parasitic on the broader exchange economy we call “the free market”.
Buckminster Fuller gave us the concept of “ephemeralization”, technology becoming both more effective and less expensive as the physical resources invested in early designs are replaced by more and more information content.
In the open-source world, you seek the largest possible user base, so as to get maximum feedback and the most vigorous possible secondary markets; in the closed-source you seek as many buyers but as few actual users as possible.
Just how worried became apparent when the now-infamous Halloween Documents (http://www.opensource.org/halloween/) leaked out of Microsoft.
We half-joke about “world domination”, but the only way we will get there is by serving the world. That means J. Random End-User and his Aunt Tillie; and that means learning how to think about what we do in a fundamentally new way, and ruthlessly reducing the user-visible complexity of the default environment to an absolute minimum.
Computers are tools for human beings. Ultimately, therefore, the challenges of designing hardware and software must come back to designing for human beings — all human beings.
In Programing Pearls, the noted computer-science aphorist Jon Bentley comments on Brooks’s observation with “If you plan to throw one away, you will throw away two.” He is almost certainly right. The point of Brooks’s observation, and Bentley’s, isn’t merely that you should expect first attempt to be wrong, it’s that starting over with the right idea is usually more effective than trying to salvage a mess.
the costs of duplicated work tend to scale sub-qadratically with team size — that is, more slowly than the planning and management overhead that would be needed to eliminate them.
