More on this book
Community
Kindle Notes & Highlights
The success of any industry is almost directly related to the degree of freedom the suppliers and the customers of that industry enjoy. Just compare the innovation in the U.S. telephone business since AT&T lost its monopoly control over American consumers with the previously slow pace of innovation when those customers had no freedom to choose.
I think it more respectful to puzzle and challenge an audience than to bore and insult it.
The beginnings of the hacker culture as we know it today can be conveniently dated to 1961, the year MIT acquired the first PDP-1.
DARPA deliberately turned a blind eye to all the technically “unauthorized” activity; it understood that the extra overhead was a small price to pay for attracting an entire generation of bright young people into the computing field.
“Given enough eyeballs, all bugs are shallow
Every good work of software starts by scratching a developer’s personal itch.
Good programmers know what to write. Great ones know what to rewrite (and reuse).
They know that you get an A not for effort but for results, and that it’s almost always easier to start from a good partial solution than from nothing at all.
“Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11) Or, to put it another way, you often don’t really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once.
If you have the right attitude, interesting problems will find you.
When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
Robert Heinlein famously wrote of one of his characters, too lazy to fail.
Release early. Release often. And listen to your customers.
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. Or, less formally, “Given enough eyeballs, all bugs are shallow.” I dub this: “Linus’s Law”.
Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect
Linus’s Law can be rephrased as “Debugging is parallelizable”. Although debugging requires debuggers to communicate with some coordinating developer, it doesn’t require significant coordination between debuggers.
Brooks (the author of The Mythical Man-Month) even made an off-hand observation related to Jeff’s: “The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs.” [emphasis added].
The fundamental problem that traditional software-development organization addresses is Brook’s Law: “Adding more programmers to a late project makes it later.” More generally, Brooks’s Law predicts that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly.
It’s no fun to be responsible for fixing bugs in a program you don’t understand.
Smart data structures and dumb code works a lot better than the other way around.
If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
Interestingly enough, you will quickly find that if you are completely and self-deprecatingly truthful about how much you owe other people, the world at large will treat you as though you did every bit of the invention yourself and are just being becomingly modest about your innate genius.
Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
Don’t hesitate to throw away superannuated features when you can do it without loss of effectiveness.
“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.”
Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
A security system is only as secure as its secret. Beware of pseudo-secrets.
It is truly written: the best hacks start out as personal solutions to the author’s everyday problems, and spread because the problem turns out to be typical for a large class of users. This
consequences, I began to appreciate the difference between acting on the principle of command and discipline and acting on the principle of common understanding. The former works admirably in a military parade, but it is worth nothing where real life is concerned, and the aim can be achieved only through the severe effort of many converging wills.
(One may call their motivation “altruistic”, but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist).
Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.
software project management has five functions: To define goals and keep everybody pointed in the same direction To monitor and make sure crucial details don’t get skipped To motivate people to do boring but necessary drudgework To organize the deployment of people for best productivity To marshal resources needed to sustain the project
Open-source projects, when they founder, essentially never do so for want of machines or links or office space; they die only when the developers themselves lose interest.
Thoughtful managers have understood for a long time that if conventional software management’s only function were to convert the least able from a net loss to a marginal win, the game might not be worth the candle.
Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A
The most important characteristic of a fork is that it spawns competing projects that cannot later exchange code, splitting the potential developer community.
The taboos of a culture throw its norms into sharp relief.
The simplest way is the command hierarchy. In command hierarchies, scarce goods are allocated by one central authority and backed up by force. Command hierarchies scale very poorly;Note 27 they become increasingly brutal and inefficient as they get larger.
Our society is predominantly an exchange economy. This is a sophisticated adaptation to scarcity that, unlike the command model, scales quite well. Allocation of scarce goods is done in a decentralized way through trade and voluntary cooperation (and in fact, the dominating effect of competitive desire is to produce cooperative behavior).
Abundance makes command relationships difficult to sustain and exchange relationships an almost pointless game.
oft-cited
Hackers like to say that “authority follows responsibility
In the absence of survival issues, reputation enhancement becomes the driving goal, which encourages sharing of new ideas and research through journals and other media.
Indeed, it seems the prescription for highest software productivity is almost a Zen paradox; if you want the most efficient production, you must give up trying to make programmers produce. Handle their subsistence, give them their heads, and forget about deadlines. To a conventional manager this sounds crazily indulgent and doomed—but it is exactly the recipe with which the open-source culture is now clobbering its competition.
In modern science, 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. Arthur C. Clarke connected the two by observing that “Any sufficiently advanced technology is indistinguishable from magic
The use value of a program is its economic value as a tool. a productivity multiplier. The sale value of a program is its value as a salable commodity. (In professional economist-speak, sale value is value as a final good, and use value is value as an intermediate good.)
What they know is this: the price a consumer will pay is effectively capped by the expected future value of vendor service (where “service” is here construed broadly to include enhancements, upgrades, and follow-on projects). In other words, software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.
