Mark Gilbert's Blog

Science and technology, served light and fluffy.

How to start a new project

“A good beginning makes a good end.” – English Proverb

When I get the opportunity to start a new project, the first thing I do is create just enough of the application that I can build it and get something tangible on the other side (for a web site that’s usually the Default page, the Web.config, and the compiled assembly; for a desktop/console app that’s usually just the executable itself).   The second thing is I’ll establish the build process.  A “build” for me means pulling source down from source control, compiling, running unit tests, packaging and deploying.  CruiseControl.NET and NAnt are my two tools of choice, but there are many others.  Putting the build process in place now has several advantages.

First, it means that the build process becomes reliable and invisible, right from the beginning.  I want to be able to add a new page to my web site (for example) and know that that page will be correctly and completely included in the package that I send to the client.  Oh yeah, and I want to not have to think about it every time.

Second, putting the build process in place when the application is in its infancy allows me to grow it with the application.  That means I can keep the application and the process that builds it in sync, and greatly reduce the risk that I’ll forget to include something in the final package.  There’s nothing more frustrating than spending weeks or months building a great web site or app, only to have it break in production because you forgot to deploy some critical file added back on Day 3.  It’s like jumping over the Grand Canyon and making it 98% of the way – the end is close, but it won’t be pretty.

Third, having the build process in place from the beginning makes it very easy and painless to do a rebuild.  If I have it working in Development and now I need to go to Stage, no problem – add Stage as a new possible destination and force a build.  If I need to set up a new copy of Stage because the client wants to review it this afternoon, no problem – adjust the build script to the new destination path and force a build.  If something doesn’t look right in the Development environment, no problem – just blow it away and force a build.

In the end, it’s all about where you start that makes the difference between success and a very late night.

Advertisements

March 29, 2010 - Posted by | Software Process

1 Comment

  1. […] and regional events. To kick things off, I’m expanding a blog post I made back in March titled “How to start a project” into a presentation.  My first delivery will be at the June 24 MDSM meeting, here in […]

    Pingback by How to start a new project – redux « Mark Gilbert’s Blog | June 9, 2010


Sorry, the comment form is closed at this time.

%d bloggers like this: