3 Tips for Getting that Large Project Going

Introduction

In the past, I have had a hard time getting large projects off the ground. I kept thinking about all of the technical details, which libraries and languages I will use, and how successful the project will be once it is finished.

The problem is, I never started on the work. Every time I got 20 minutes or an hour to work on it, all I could think about were these technical details.

I have long since learned from my mistakes and have found 3 general processes for getting large programming projects off the ground. If you're stuck in design mode, try giving these methods a shot:

Method 1 - Requirements Are The Key

Write only the generic requirements on a single sheet, in a binder on its own, or in a single document.

Keep the requirements short and sweet.

Keep all technical notes that you just can't stop thinking about elsewhere - they are not important in this phase. If possible, don't write them down at all. You will think of them later (or better ideas) and you don't want to force yourself into the wrong library later.

Think about how you will use this application/library, what will be difficult, what will be beneficial (again staying away from technical details including the language and library).

Begin writing code or manipulating wire frames as if you are using your newly completed project. Keep this "test code" for reference but don't make it the golden rule.

Collect flaws and focus areas and add them to a "things to consider" sheet.

Start writing simple implementation code starting at the easiest thing first (very similar to TDD but without the tests).

Success

I have used this method for some of my larger research type projects. It was very easy to adopt.

Failure

Three projects using this method never made it past this phase due to marketability and usability factors that were exposed. They seemed like fun research projects but were not practical so they remained a paper-only experiment.

Method 2 - Spike It

Maybe the best thing to do is a quick Spike (term from XP). Simply start writing a bunch of code you won't keep but will learn from. You get a feel for the project and end up writing version 2 first.

Success

I have used this successfully when picking up a modified version of the MVP pattern and some complex UI code.

Failure

I have kept the code written using this method due to time constraints. It has bitten me and was rewritten at a later date.

Warning

This works best for new requirements to existing systems. New projects also benefit as long as you are disciplined enough to toss the spike when you're finished with it.

Method 3 - TDD It To Death

This method is the hardest to master but one of the most powerful. Using Test Driven Development to work top-down (never TDD up) is very fun and productive.

First you starting at what you want to be the outcome (your initial requirements). Continue testing down until it is the implementation.

This takes practice especially when writing and maintaining the requirements list the TDD way. Refactoring and writing as little as possible while still adding value is also difficult when you've been writing legacy code for so long.

This method helps isolate dependencies so you can replace them easily if requirements change down the road.

Success

I have used this for a simple C# device interface project and a string template class. Both were to help learn TDD and both were never 100% completed. These projects had a lot of power, worked very well, and the code looked like a work of art.

Failure

This has failed just as many times as it succeeded for me. The reason was simply not knowing TDD, how to write requirements, and keeping myself from writing more code than I need to.

Summary

Start doing something NOW! Don't wait, think more, put it off... start doing something. Even failures are learning experiences. You cannot succeed if you don't try.

Good luck!