Coder to Developer: Tools and Strategies for Delivering Your Software

Before thinking about effective teamwork, it’s worth considering why you might want to work with a team in the first place. After all, no matter how well your team functions as a unit, there’s going to be some overhead incurred in communicating with team members, assigning work, integrating different people’s efforts, and so on. Here are some good reasons for undertaking development as part of a team rather than as a lone wolf:

• Labor pool Some projects are simply too large for a single developer to undertake. You might be able to easily develop a project with a dozen classes, and after some time you could extend that to include a hundred or so classes. But what do you do when your initial analysis indicates that you need five hundred classes? A thousand? Ten thousand? At some point, even with the best organization and code generation tools, you’ll need to bring in additional help simply to get the job done.

• Deadlines Even if you can finish the hundred-class project, can you finish it soon enough to do you any good? Whether it’s the market pressure of wanting to be the first one selling software in a new niche, or the client pressure of delivering a business application by an arbitrary contractual deadline, you usually won’t have the luxury of working on a software project for as long as you might like. Sometimes you’ll need additional hands just to get the job done in time for it to make a difference.

• Skills If there’s one thing you should learn from this book, it’s that creating a successful software application involves more skills than just writing code. Someone needs to create documentation and help files, graphics, a website, an installer application, and so on. While you could master all of the necessary skills in time, it may be a better use of your energies to focus on just a few of the necessary areas and find partners who can help with the rest.

The bottom line is that whether or not you’re a lone wolf at heart, there are times when working with a team to produce high-quality software makes sense. For the rest of this chapter, I’ll assume that you’re trying to write software with a team and want to do an effective job. And, since it’s your application I’m talking about, I’ll assume that you’re most likely the manager of the team as well.

Although this is a chapter about working with teams, I want to spend a little while talking about working alone first. Not every software project can be effectively done by a team, and not every developer can work effectively on a team. While I encourage you to be flexible, and to consider a development team when it makes sense, here are some reasons why you might choose to work alone instead:

• Small projects Some projects are small enough that they don’t require a team to finish. In such cases, you might well choose to go it alone, just to avoid the overhead of introducing a team to the process. But before making a decision strictly based on size, remember that even small projects can benefit from a good team.

• Psychology Did your report card consistently say “doesn’t play well with others”? Do you feel like that’s still the case, and you don’t see anything wrong with this state of affairs? In that case, you might not be good team material yourself. Or perhaps you’ve been burned by a bad team experience in the past (for example, being stuck with team members who wouldn’t pull their weight). If the very thought of teamwork makes you ill, you might have to concentrate on finding projects that you can do alone.

• Opportunity If you’re the only software developer in Left Flank, Missouri, your opportunities for building a successful team may be pretty limited. Don’t be too quick to make this assumption, though; later in this chapter I’ll talk about strategies for building a geographically distributed team.