Response Crafting

The Cathedral + The Bazaar

Leave a comment

Good software development has a lot to do with releasing early, releasing often, nurturing those who are involved, and fostering a very particular culture.

From The Cathedral and The Bazaar by Eric S. Raymond:

All good work starts by scratching a personal itch.

Good creators know what to build. Great ones know what to rebuild (and reuse).

Release early. Release often. Throw your work away.

I wrote before about the merits of destroying your work and the high risks of hoarding it. When you hold your work close to your chest, it becomes about the artifacts rather than the ongoing act of creating them. You end up with things that are more precious than valuable, and become increasingly stale over time. Don’t hoard. The value is in creating, not sitting on a stack of creations. “Plan to throw one away; you will, anyhow.” – Frederick Brooks, The Mythical Man-Month

It seems this is particularly difficult for those in design, who instead often seem preoccupied with the creation (and presentation) of artifacts. 

If you have the right attitude, interesting problems will find you.

And listen to your customers.

If you treat your early users as if they’re your most valuable resource, they will respond by becoming your most valuable resource.

If you treat anybody like they’re invaluable, odds are pretty good that they eventually will be. It’s Dale Carnegie’s old principle of giving “the other person a fine reputation to live up to” or “giving a dog a good name.” If you want to improve a person in a certain aspect, act as though that particular trait were already one of his or her outstanding characteristics. “The average person,” said Samuel Vauclain, once president of the Baldwin Locomotive Works, “can be led readily if you have his or her respect and if you show that you respect that person for some kind of ability.” Give them a fine reputation to live up to, and they will make prodigious efforts rather than see you disillusioned.

The next best thing to having good ideas is recognizing good ideas from others. Sometimes the latter is better.

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

“I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.”

Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

With pretty much everything, “robust and simple”  > “cute and complicated”

Beware of all enterprises that uphold their creations as “perfect.” Beware the company “darlings.” Be very wary of anything “precious.”

“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.”

Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry.)

Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

A thing must first work as expected. Only after it achieves that can it go on to do other things. And our adoration should be preserved for those tools that offer both.

One of the worst offenders of this rule is the garlic press, which seems to be revered only by bad designers and amateur cooks, and abhorred by most everyone else. I’ve written about it before, but the problem is that the garlic press violates both of these rules: at best, it’s a one-trick pony, promising no more utility beyond pressing garlic. But that’s assuming it’s even capable of that task, which more often than not, it’s not.

To solve an interesting problem, start by finding a problem that is interesting to you.

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.

The problems with Cathedral-style and conventional management of software:

  • “In the cathedral-builder view of programming… 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.”

“And I listened to my beta testers, polling them about design decisions and stroking them whenever they sent in patches and feedback.”

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 like you did every bit of the invention yourself and are just being becomingly modest about your innate genius


1. Have humility

ESR believes in both extroversion and “egolessness” – the creator who can put himself out there without taking all of the credit, stealing the spotlight, or coercing the team.

As a non-technical, I have a lot of respect for those “doers” of the world, almost regardless of their level of brilliance. All of them are better at their craft than I am. But I have even more respect for those “doers” that exude humility and self-deprecation, much like ESR does when, before launching into a technical section, he disclaims it with: “If you don’t care about the technicalia of Internet mail, the next two paragraphs can be safely skipped” or “Nontechnical readers can safely skip this section.”

It’s important at the development level, but it’s even more important at the management level. Bazaar projects “cannot be based on power relationships – and even if they could be, leadership by coercion would not produce the results we see.”

2. Have passion

If you think that love has no place here, you are wrong.

ESR writes, regarding his fellow developers, that “neither of us was ‘original’ in the romantic way people think is genius. But then, most science and engineering and software development isn’t done by original genius, hacker mythology to the contrary.”

3. Start with something to build on

“One cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaarmode.”

We all get our ideas from somewhere, and everything – in art as in technology – is an evolution of its predecessors.

4. Offer a “plausible promise”

Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future.

5. Build rapport

You must have good people and communications skills. This should be obvious. In order to build a development community, you need to attract people, interest them in what you’re doing, and keep them happy about the amount of work they’re doing. Technical sizzle will go a long way towards accomplishing this, but it’s far from the whole story. The personality you project matters, too.

6. Take care

If you’re writing for the world, you have to listen to your customers – this doesn’t change just because they’re not paying you in money.

“The Linux world behaves in many respects like a free market or an ecology, a collection of selfish agents attempting to maximize utility which in the process produces a self-correcting spontaneous order more elaborate and efficient than any amount of central planning could have achieved.”

“I think it is not critical that the coordinator be able to originate designs of exceptional brilliance, but it is absolutely critical that the coordinator be able to recognize good design ideas from others.”

That might be it, really, in short. The ability to “good.” Recognize good, foster good, do good.



Share your thoughts

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s