検索対象: The Best Software Writing I. Selected and Introduced by Joel Spolsky
100 THE BEST SOFTWARE WRITING I The FinaI Frontier After software, the most important tool to a hacker is probably his office. Big companies think the function Of Office space is tO express rank. But hackers use their offices for more than that: they use their office as a place t0 think in. And if you're a technology company, their thoughts are your product. SO making hackers work in a noisy, distract- ing envlronment is like having a paint factory where the air is full Of SOOt. The cartoon strip Dilbert has a 10t to say about cubicles, and with good reason. AII the hackers I know despise them. The mere prospect 0f being interrupted is enough tO prevent hackers from working on hard problems. If you want t0 get real work done in an office with cubicles, you have tWO options: 、 at home, or come early or late or on a weekend, When no one else iS there. Don't compames realize thiS iS a S1gn that something is broken? An Office envlronment is supposed tO be something you work in, not something you work despite. Companies like CiSCO are proud that everyone there has a cubicle, even the CEO. But they're not so advanced as they think; obviously they still view Office space as a badge Of rank. NOte t00 that Cisco is famous for doing very little product development in house. They get new tech- nology by buying the startups that created it—where presumably the hackers did have somewhere quiet tO work. One big company that understands what hackers need is Microsoft. I once saw a recruiting ad for Microsoft with a big picture Of a door. Work for us, the premise was, and we'll give you a place to work where you can actually get work done. And you know, Microsoft is remarkable among big companies in that they are able tO develop software in house. Not well, perhaps, but well enough. If companies want hackers t0 be productive, they should look at what they do at home. At home, hackers can arrange things themselves so they can get the most done. And when they work at home, hackers don't work in n01SY, open spaces; they work in rooms with doors. They work in cozy, neighborhoody places with people around and somewhere to walk when they need to mull something over, instead of in glass boxes set ⅲ acres 0f parking 10ts. They have a sofa they can take a nap on
MARY POPPENDIECK 161 Dysfunction # 2 : The Perception ofUnfairness There is no greater demotivator than a reward system that is perceived tO be unfair. lt doesn't matter whether the system is fair or not. If there is a perception Of unfairness, then those whO think that they have been treated unfairly will rapidly lose their motivation. people perceive unfairness when they mlSS out on rewards they think they should have shared. What if the vice president had given Sue a big reward but not rewarded the team? Even if Sue had acknowledged the hard work of her team members, they would probably have felt that she was profiting at their expense. You can be sure that Sue would have had a difficult time generating enthusiasm for work on the next release, even if the evaluation issues had not surfaced. Here's another scenano: what would have happened if Sue's team had been asked out to dinner with the VP and each member had been given a good-sized bonus? The next day the operations people wh0 worked late nights and weekends t0 help get the product out on time would have found out and felt cheated. The developers who took over maintenance tasks SO their colleagues could work full time on the prod- uct also would have felt slighted. Other teams might have felt that they could have been equally successful, except that they got assigned t0 the wrong product. Dysfunction # 3 : The Perception oflmpossibility sue's team met its deadline by following the Scrum practice 0f releasing a high-quality product containing only the highest-priority functionality. But let's try a different scenario: let's assume that the team was gwen a non-negotiable list 0f features that had t0 be done bY a non-negotiable deadline, and let's further speculate that the team was 100 percent
PAUL GRAHAM 97 That's not a new idea. Fred Brooks wrote about it in 1974 3 and the study he quoted was published in 1968. But I think he underestimated the varlation between programmers. He wrote about productivity in lines Of code: the best programmers can solve a given problem in a tenth of the time. But what if the problem isn't given ~ ln programming, as in many fields, the hard part isn't solving problems, but deciding what problems tO SOlve. lmagrnation is hard tO measure, but in practice it dominates the kind Of productivity that's measured in lines Of COde. Productivity varies in any field, but there are few in which it varies so much. The variation between programmers IS SO great that it becomes a difference in kind. I don't think this is something intrinsrc tO program- ming, though. ln every field, technology magnifies differences in productivity. I think what's happening in programmmg is just that we have a 10t of technologicalleverage. But in every field the lever is getting longer, SO the variatlon we see IS something that more and more fields Will see as tlme goes on. And the success Of compames, and countnes, will depend increasingly on how they deal with it. If variation in productivity increases with technology, then the contribution Of the most productive individuals will not only be dispro- portionately large but will actually grow with time. When you reach the point where 90 % 0f a group's output is created by 1 % 0f its members, you lose big if something (whether Viking raids, or central planning) drags their productivity down tO the average. If we want tO get the most out Of them, we need tO understand these especially productive people. What motivates them? What d0 they need to do their jobs? How do you recognize them? How do you get them to C01 れ e and work for you? And then Of course there's the question, hO 、 dO you become one ~ Morethan Money I know a handful of super-hackers, so I sat down and thought about what they have in common. Their defining quality is probably that they 3. . in his book The M ァ 舫 Ma 〃 Mo れ 舫 . ー Ed.
CLAY SHIRKY 199 Part Three: What Can We Take for Granted? If these assumptions are right—first that a group is lts own worst enemy, and second, we're seeing this explosion Of social software—what should we do ~ Can we say anything with any certainty about building social software, at least for large and long-lived groups? I think we can. A little over 10 years ago, I quit my day job, because Usenet was SO interesting. I thought at the time, is really gomg tO be big. " And I actually wrote a book called た お 〃 0 川 ル Net, about Net culture at the time, Usenet, the WeII, Echo, IRC, and so forth. lt was published in April of ' 95 , just as that world was being washed away by the 嶬 eb. But it was my original interest, SO l've been looking at this problem in one way or another for 10 years, and l've been looking at it pretty hard for a year and a half or so. So there's this question: "What is required to make a large, long-lived I think I can answer With S01 れ e confi- online group successful? " dence: "lt depends. ' ' (l'm hoping t0 flesh that answer out a little bit in the next 10 years. ) But I can atleast say some of the things it depends on. The Calvinists had a doctrine Of natural grace and supernatural grace. Natural grace was, "You have t0 d0 all the right things in the world t0 get t0 heaven.. .. and God has to anoint you. " And you and supernatural grace 、 never knew if you had supernatural grace or not. This was their way Of getting around the fact that the b00k 0f Revelation put an upper limit on the number 0f people who were going t0 heaven. Social software is like that. You can find the same piece 0f code run- mng in many, many envlronments. And sometimes lt and sometlmes it doesn't. SO there is something supernatural about groups, where having good software alone isn't enough, because the social behavior Of groups IS a runtime experience.
ERIC SINK 241 There are several opportunities here to make things easy for your customer. Don't miss out on any Of the following: Make the DownIoad Easyto Find You probably think your download is easy to find. After all, you know right where it is, right? Don't assume. Grab a stranger (don't actually grab them) and ask them t0 visit your website and find the demo download. ・ Watch them search and see hOW long it takes. Make the Download Full-Featured The best demo download is the product itself. Every SourceGear prod- uct has only one binary available for download. The demo version 1S exactly the same binary as the full product. Every feature is enabled, but only for 30 days. TO make a purchase, the customer simply enters a serial number and does not have tO reinstall. PolishYour lnstaller Your demo download is your opportunity tO make a positive first impression. lt is indescribably important that your demo JLISt works. ' If anything goes wrong, your customer will probably just lose interest and you will have lOSt the chance tO be responslve. Let the Customer Remain Anonymous The hyperlink to your demo download should link directly to the actual binaries. Don't make users fill out a form and give their contact infor- mation. ThiS iS responsive sales, and the users are in charge. Let them decide when they want t0 make themselves known to you, if at all. 5. Answerthe Customers' Questions I am a big believer in the importance of giving excellent technical sup- port. When your customers have problems, you need to stop and help
96 THE BEST SOFTWARE WRITING I (THIS ESSAY IS DERIVED FROM A KEYNOTE TALK AT OSCON 2004. ) few months ago I finished a new book, and in revlews I keep notic- ing words like "provocative" and "controversial. " TO say nothing Of "idiotic. " I didn't mean tO make the bOOk controversial. I was trying tO make it efficient. I didn't want tO waste people's time telling them things they already knew. lt's more efficient just t0 give them the diffs. 2 But I SUppose that's bound t0 yield an alarming b00k. Edisons There's no controversy about which idea is most controversial: the sug- gestion that variation in wealth might not be as big a problem as we think. I didn't say in the book that variation in wealth was in itself a good thing. I said in some situations it might be a sign 0f good things. A throb- bing headache is not a good thing, but it can be a sign 0f a good thing—for example, that you're recovenng conscrousness after being hit on the head. Variat10n in wealth can be a S1gn Of variation in productivity. ()n a society 0f one, they're identical. ) And that is almost certainly a good thing: if your society has no variation in productivity, it's probably not because everyone is Thomas Edison. lt's probably because you have no Thomas Edisons. ln a low-tech SOCiety you don't see much variation in productivity. If you have a tribe Of nomads collecting sticks for a fire, hOW much more productive is the best stick gatherer going tO be than the worst? A factor of two ~ Whereas when you hand people a complex t001 like a computer, the variatlon in what they can dO with it is enormous. 2. 、 、 Diffs" are the lines of code that have changed from one versron of a program to the next. ー Ed.
146 THE BEST SOFTWARE WRITING I Your intimacy with your product has clouded your judgment, and what you'd consider ready for prime time has nothing t0 do with whether a customer would be happy with it. lf, in a moment 0f lucidity, you real- ize that this the situation you're in, it's best tO find a person/party whose judgment you trust and get a sanity check. Your instlnct will be tO go tO your QA organization, but they're equally in love with the product and probably more whacked about quality than you are. Maybe your boss? Maybe another engmeering manager? I don't know whO, but it's got tO be someone whO has not spent the last three months living and breathing this product that's NEVER GOING TO SHIP. When you do find a designated sane person, they should ask ques- tions like 1. Are the features done? How done? Are they testable? 2. How many bugs are left? 3. How many bugs are you fixing on a daily basis? 4. How many bugs are you willing to ship with? 5. What are your bug deferral criteria? 6. What's your update strategy? This sane person's job is not to decide for you. Their J0b is to be neu- tral and to help you frame your decision by asking great questions. As a rookie manager, you re not going tO seek external input because you'll think asking for help is a S1gn of weakness and, boy, are you wrong. Asking for help from team members allows these folks to apply their unique experience tO whatever the problem might be and that's hOW you make better decisions while also building a stronger team. Asking for help is a big deal. DO it. Often. That's situation # 1 . . getting a second opinion. ThiS leads us tO SIt- uation # 2 , which is, you're right . . your product iS nowhere near ready for customers and you're 14 working days from shipping. You and your team are charging forward tO the ship date, but almost everyone is shak- ing their heads slowly and murmuring, "lt's not ready. And it's not. NO need tO get a second opinion. You're still finishing features. QA is sufficiently pissed off and your program manager is cry- ing in his/her office. Yes, it's really not ready.
PAU L GRAHAM 103 Nasty Little Problems lt's pretty easy tO say what kinds Of problems are not interesting: those where instead 0f solving a few big, clear, problems, you have t0 solve a 10t Of nasty little ones. One Of the worst kinds Of projects is writing an interface t0 a piece 0f software that's full 0f bugs. Another is when you have tO customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts. The distinguishing feature of nasty little problems is that you don't learn anything from them. Writing a compiler iS interesting because it teaches you what a compiler is. But writing an interface tO a buggy P1ece Of software doesn't teach you anything, because the bugs are random. 7 SO it's not just fastidiousness that makes good hackers avoid nasty little problems. lt's more a question Of self-preservation. ・ Working on nasty little problems makes you stupid. G00d hackers avoid it for the same reason models avoid cheeseburgers. Of course some problems inherently have this character. And because 0f supply and demand, they pay especially well. SO a company that found a way t0 get great hackers t0 work on tedious problems would be very successful. HOW would you d0 it? One place this happens is in startups. At our startup we had R0bert Morris working as a system administrator. 8 That's like having the Rolling Stones play at a bar mitzvah. You can't hire that kind 0f talent. But people will d0 any amount 0f drudgery for companies 0f which they're the founders. 9 7. 8. 9. I think this is what people mean when they talk about the 、 、 meaning oflife. " On the face Of it, this seems an Odd idea. Life isn't an expression; hOW could it have meaning? But it can have a quality that feels a lotlike meaning. ln a project like a compiler, you have t0 solve a 10t of problems, but the problems all fall into a pattern, as in a signal. ・ Whereas when the problems you have tO SOlve are random, they seem like noise. RObert MorriS IS one Of the leading experts on Unix networking. He iS now a professor at MIT. ー Ed. Einstein at one point worked designing refrigerators. ()e had equity. )
244 THE BEST SOFTWARE WRITING I Does your online store ビ 4 ″ ア need tO create a user account for every- body who makes a purchase? Probably not. Can't you Just take their money and give them software? Probably. You Don't Need a Shopping Cart I think Amazon1 t00 heavily influences the expectations for online shopping. ln my opinion, Amazon has a really incredible shopping cart system. lt is extremely powerful, and yet it feels extremely simple. SO Ⅵ ℃ convmce ourselves that our online store needs tO be as C001 as Amazon's, but that just isn't true. Amazon truly is an online store. The shopping cart metaphor makes sense. The Amazon store IS lmmensely large and contains a staggenng number Of products. lt's a pleasant place. lt only makes sense that we would want tO leisurely wander around the store, selecting various products as we go, stopping at the checkout line on our way out t0 pay the bill. Your small ISV simply doesn't function on that kind of scale. You are more like a hot dog stand than a store. You sell only a few products; per- haps only one. Your customer has no interest in leisurely walking around and browsing the vastness 0f your product offerings. They came t0 buy a hot dog and they don't understand why you expect them to place it in a big shopping cart and walk halfway down the block to go pay for it. I speak from experience and mistakes. Until recently, the SourceGear online sales system was an extremely poor clone Of Amazon. ln a maJOr rewrite, we eliminated the shopping cart and simplified the entlre order- lng process t0 a single form. Everything is much simpler now. Give Customers the Product Right Away lt's fine if you need to ship some sort 0f physical object to your cus- tomers. However, don't make them wait for the media or documentation before they can get started. lmmediately after the user places an order, let the user download the bits and start using it right away. Even better, glve serial numbers tO the users tO simply activate the demo(s) they are already using. 10. See http://www.amazon.com/
194 THE BEST SOFTWARE ・ WRITING I different practice. ln the political realm, we would call these kinds of crlses a constitutional crisis. lt's what happens when the tension between the individual and the group, and the rights and responsibilities of indi- viduals and groups, gets SO serious that something has tO be done. And the worst cr1SIS is the first crisis, because it's not just "We need tO have some rules. lt's alSO "We need tO have some rules for making S01 れ e rules. ' ' And thiS iS What we see over and over agaln in large and long-lived SOCial SOft 、 systems. Constitutions are a necessary com- ponent oflarge, long-lived, heterogeneous groups ・ Geoff Cohen has a great observation about this. He said, "The like- lihood that any unmoderated group will eventually get into a flame-war about whether or not tO have a moderator approaches one as time lncreases. ' ' AS a group commlts tO itS existence as a group, and begins tO think that the group is good or important, the chance that they will begin t0 call for additional structure, in order t0 defend themselves from themselves, gets very, very high. Part Two: Why Now? If these things l'm saying have happened so often before, have been happemng and been documented and we've got psychologicalliterature that predates the lnternet, what's gOIng on now that makes this impor- tant? I can't tell you precisely why, but observationally there is a revolution in social software going on. The number 0f people writing t001S t0 sup- port or enhance group collaboratlon or communication iS astonishing. The 嶬 b turned us all into size queens for six or eight years there. lt was loosely coupled, it was stateless, it scaled like crazy, and everything became about how big you could get. "HOW many users does Yahoo have ~ H()W many customers does Amazon have ~ イ 0 、 many .readers does MSNBC have?" And the answer could be "A 10t ! " But MSNBC, say, could only get a 10t if they didn't have t0 be talking with their users, Just talking t0 them, and they didn't have t0 figure out a way to let those readers talk tO each Other.