In software management, coordination is not an afterthought or an ancillary matter; it is the heart of the work, and deciding what tools and methods to use can make or break a project. But getting sidetracked in managing those tools is a potent temptation. When the cry of "Let's build it ourselves!" arises, geeks are all too happy to rally and cheer. A celebrated (and perhaps apocryphal) bit of graffiti from MIT captures this: "I would rather write programs to help me write programs than write programs." Similarly, there is a saying attributed to Abraham Lincoln: "Give me six hours to chop down a tree, and I will spend the first four sharpening the axe." This principle, which found its way into the business advice manual The 7 Habits of Highly Effective People, appeals to every programmer's passion for toolmaking. But if it becomes an end in itself, it can drive the best-organized project into a ditch.

"Unfortunately," Constantine wrote, "most programmers like to program. Some of them would rather program than eat or bathe. Most of them would much rather cut code than chase documentation or search catalogs or try to figure out some other stupid programmer's idiotic work. Other things being equal, programmers design and build from scratch rather than recycle."... "If it takes the typical programmer more than two minutes and twenty-seven seconds to find something," Constantine wrote, "they will conclude it does not exist and therefore will reinvent it." ... There is almost always something you can pull off the shelf that will satisfy many of your needs. But usually the parts of what you need done that your off-the-shelf code won't handle are the very parts that make your new project different, unique, innovative, and they're why you're building it in the first place... What they all share is a passion for specialized knowledge and a troubled relationship - at best clumsy, at worst hostile - with everyone who lacks that passion. You mean you don't know how to configure your home network?

Andy Hertzfeld tells a relevant tale from the early days at Apple about his mentor Bill Atkinson, a legendary software innovator who created Quickdraw and Hypercard. Atkinson was responsible for the graphic interface of Apple's Lisa computer (a predecessor of the Macintosh). When the Lisa team's managers instituted a system under which engineers were expected to fill out a form at the end of each week reporting how many lines of code they had written, Atkinson bridled. "He thought that lines of code was a silly measure of software productivity," wrote Hertzfeld in his account of Macintosh history, Revolution in the Valley. "He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code." The week that he was asked to fill out the new management form for the first time, Atkinson had just completed rewriting a portion of the Quickdraw code, making it more efficient and faster. The new version was 2000 lines of code shorter than the old one. What to report? He wrote in the number -2000.

"Management," wrote Peter Drucker, the late business philosopher, "is about human beings. Its task is to make people capable of joint performance, to make their strengths effective and their weaknesses irrelevant." We're accustomed to thinking of management as the application of business school techniques that carry a scientific sheen: uniform measurements of productivity and metrics of return-on-investment. Drucker's definition sounds awfully squishy; he could be talking about an orchestra conductor or a stage director. But in emphasizing the art of management over the science, the human realm over the quantitative dimension, Drucker - who first invented the term knowledge worker and then offered invaluable insights into its implications - was trying to remind us that numbers are only a starting point for management, not its ultimate goal.

When people dream of streamlining the work of making software, most often they dream of standardized plug-in parts. James Noble and Robert Biddle, two scholars in New Zealand who sometimes write together under the sobriquet The Postmodern Programmers, dub this vision the Lego Hypothesis: "In the future, programs will be built out of reusable parts. Software parts will be available worldwide. Software engineering will be set free from the mundane necessity of programming." Pull some pieces off the shelf, snap them together, and presto: working software, with no painful coding! Programmers who have tried to travel the road to this utopian vision of programming have almost always found it blocked...

If software components were like Lego bricks, they'd be small, indivisible, and substitutable; they'd be more similar to one another than different; they'd be "coupled to only a few, neighboring components." But Noble and Biddle found that the components in actual programs varied enormously in size, in function, and in their number of connections to other components. They were "scale-free, like fractals, and unlike Lego bricks." When they peered under the hood of real programs, Noble and Biddle observed what they called "pervasive heterogeneity": Everywhere you looked, the only constant was that nothing was constant...