On teams, hiding is considered harmful
Future-proof your project's success by working in a team.
Tug of War. (source: By toffehoff on Flickr.)
Editor’s note: This is an excerpt from Debugging Teams, by Brian W. Fitzpatrick and Ben Collins-Sussman.
If you spend all your time working alone, you’re increasing the risk of failure and cheating your potential for growth.
Learn faster. Dig deeper. See farther.
First of all, how do you even know if you’re on the right track?
Imagine you’re a bicycle-design enthusiast, and one day you get a brilliant idea for a completely new way to design a gear shifter. You order parts and proceed to spend weeks holed up in your garage trying to build a prototype. When your neighbor—also a bike advocate—asks you what’s up, you decide not to talk about it. You don’t want anyone to know about your project until it’s absolutely perfect. Another few months go by and you’re having trouble making your prototype work correctly. But because you’re working in secrecy, it’s impossible to solicit advice from your mechanically inclined friends.
Then one day, your neighbor pulls his bike out of his garage with a radical new gear-shifting mechanism. Turns out he’s been building something very similar to your invention, but with the help of some friends down at the bike shop. At this point, you’re exasperated. You show him your work. He points out that your design had some simple flaws—ones that might have been fixed in the first week if you had shown him.
There are a number of lessons to learn here. If you keep your great idea hidden from the world and refuse to show anyone anything until the implementation is polished, you’re taking a huge gamble. It’s easy to make fundamental design mistakes early on. You risk reinventing wheels (Literally, if you are, in fact, a bike designer). And you forfeit the benefits of collaboration, too: notice how much faster your neighbor moved by working with others? This is why people dip their toes in the water before jumping in the deep end: you need to make sure that you’re working on the right thing, you’re doing it correctly, and it hasn’t been done before. The chances of an early misstep are high. The more feedback you solicit early on, the more you lower this risk. (We should note that sometimes it’s dangerous to get too much feedback too early in the process, but we’ll cover that in a later chapter.) Remember the tried-and-true mantra of “fail early, fail fast, fail often”—we’ll discuss the importance of failure at length later in the book.
Early sharing isn’t just about preventing personal missteps and getting your ideas vetted. It’s also important to strengthen what we call the “bus factor” of your project.
Bus factor (noun): the number of people that need to get hit by a bus before your project is completely doomed.
How dispersed is the knowledge and know-how in your project? If you’re the only person who understands how the prototype code works, it may be nice job security, but it also means the project is toast if you get hit by a bus. If you’re working with a friend, however, you’ve doubled the bus factor. And if you’ve got a small team designing and prototyping together, things are even better—the project won’t be over when a team member disappears. Remember: team members may not literally get hit by buses, but other unpredictable life events still happen. Someone may get married, have to move away, leave the company, or have to take care of a sick relative. You need to future-proof a project’s success by managing the bus factor.
Beyond the bus factor, there’s the issue of overall pace of progress. It’s easy to forget that working alone is often a tough slog, much slower than people want to admit. How much do you learn when working alone? How fast do you move? The Web is a great dumping ground of opinions and information, but it’s no substitute for actual human experience. Working with other people directly increases the collective wisdom behind the effort. When you get stuck on something absurd, how much time do you waste pulling yourself out of the hole? Think about how different the experience would be if you had a couple of peers to look over your shoulder and tell you—instantly—how you goofed and how to get past the problem. This is exactly why teams sit together (or do pair programming) in software engineering companies: you often find yourself needing a second pair of eyes.
Here’s another analogy. Think about how you work with your compiler. When you sit down to write a large piece of software, do you spend days writing 10,000 lines of code, then when you think it’s all done and completely perfect, press the “compile” button for the very first time? Of course you don’t. Can you imagine what sort of disaster would result? As programmers, we work best in tight feedback loops: write a new function, compile. Add a test, compile. Refactor some code, compile. We get the typos and bugs fixed as soon as possible after generating code. We want the compiler at our side for every little step, playing wingman; some environments can even compile our code as we type. This is how we keep code quality high and make sure our software is evolving correctly bit by bit.
The same sort of rapid feedback loop is needed not just at the code level, but at the whole-project level, too. Ambitious projects evolve quickly and have to adapt to changing environments as they go. Projects run into unpredictable design obstacles, political hazards, or you simply discover that things aren’t working as planned. Requirements morph unexpectedly. How do you get that feedback loop so that you know the instant your plans or designs need to change? Answer: by working in a team. Eric Raymond is often quoted as saying, “Many eyes make all bugs shallow,” but a better version might be, “Many eyes make sure your project stays relevant and on track.” People working in caves awake to discover that while their original vision may be complete, the world has changed and made the product irrelevant.
Sadly, this problem of “clutching ideas to the chest” isn’t unique to software engineering—it’s a pervasive problem across all fields. For example, professional science is supposed to be about the free and open exchange of information. But the desperate need to “publish or perish” and to compete for grants has had exactly the opposite effect. Great thinkers don’t share ideas. They cling to them obsessively, do their research in private, hide all mistakes along the path, and then ultimately publish a paper making it sound like the whole process was effort- less and obvious. And the results are often disastrous: they accidentally duplicated someone else’s work, or they made an undetected mistake early on, or they produced something that used to be interesting but is now regarded as useless. The amount of wasted time and effort is tragic.
Don’t become another statistic.