Starting a New Project

---

If you’ve come this far, you’ve got an idea for a new application. You’ve brainstormed a list of requirements and come up with an architecture at a level of detail that suits you. Now you’re ready to set pen to paper (or, much more likely, fingers to keyboard) and start writing code. But where to start? There are three basic ways to get going on a new and reasonably large coding method:

• Breadth-first

• Depth-first

• Mixed

Breadth-First Coding

In a breadth-first strategy, the object is to rough in the entire application at once, and then go back and fill in the details later. When working this way, you’ll probably concentrate first on the interfaces between the various components. For example, defining how the core logic of Download Tracker will call the download engine would tell me something about both components; I could write the skeleton of the method in the engine, and the code to call it, without actually implementing anything.

A breadth-first approach brings some advantages with it:

• You can quickly scope out whether you left anything out of your architecture.

• It’s possible to demonstrate the overall flow of an application early in the coding cycle.

But breadth-first coding has disadvantages as well:

• If you’re working for customers, they may mistake the shell of the application for a nearly complete version, resulting in unrealistic schedule expectations.

• It can be hard to manage a team of developers on a breadth-first project, because splitting off parts of separate developers to work on is challenging.

Depth-First Coding

With a depth-first strategy, you concentrate on one piece of the application at a time. For example, using a depth-first approach to the Download Tracker application, I might start by writing the entire download engine before any other part of the application. Only when that part was written and debugged would I turn to the next task, perhaps setting up the database and data access layer.

Of course, depth-first coding offers advantages:

• By concentrating on a single task, you can research and remember the code issues associated with that task to the exclusion of all else.

• If you have a team of developers, they can work on separate components without bumping into each other’s code.

To balance these, you have to consider the disadvantages of the depth-first approach:

• You won’t have a sanity check on your architecture until late in the game.

• While you can demonstrate individual components, there’s no way to get a sense of overall application flow until you’re nearly done coding.

Mixed Models

So which approach do I advocate? For a small project, I like to take a mixed approach to development. Most of the work I do involves some UI, with functionality behind it. Download Tracker is a good example: there are UI bits, but there are also plenty of non-UI bits to work on. (Class libraries, by contrast, are all code with no UI.)

In such cases, I usually start by at least roughing in the UI. This gives me a chance to check that the application will behave in a sensible way and to think in more depth about the way that a user will interact with it. So this part of the process is breadth-first; the UI is a fa ade with nothing behind it, at least to begin with.

After I’m satisfied that the UI is close to what I want, I’ll switch to depth-first development, tackling one component at a time. This lets me focus my skills and knowledge on a single problem, without worrying about the entire application at once. In Download Tracker, for example, it makes sense to write the download engine and the data access layer as two separate tasks, since there’s not likely to be much code that can be shared between the two.

---