CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Would you do it differently today?

A year and a half ago I wrote a post called My Gameplan for Starting a New Project from Scratch that just detailed my thoughts on starting up a new project.  I was asked via email last week if I had any changes to that post.  Yes, absolutely:

Follow it Through!

Don't jump into the work too early without a good story backlog definition, an understanding of the goals of the system, and some inkling of the expectations of the client (which are undoubtedly going to turn out to be ridiculously unrealistic).

All processes, even XP and Scrum, have some sort of fuzzy project conception phase.  The activities that you perform in that phase are crucial to the success of the project by preparing the field, but easy to neglect because there isn't much pressure upfront and the feedback loop that says "you're wrong!" hasn't started yet.  On the other hand, I think you need to work with a sense of purpose early in the project to get through that initial phase and get started.  In My Gameplan post I talked about the importance of getting momentum early on in the project.  That's largely based on my experiences in a large organization that let the early phases drag on way too long.  After doing three projects and starting a fourth since that post, I'd still err a little bit on the side of starting the coding in earnest too early rather than too late. 

I did have some issues with coding outrunning the build, test, and deployment infrastructure.  Take care of that stuff as early as possible.  Especially early on the project, if you see chances to add some automation to reduce friction, do it right then.  Investments early on pay off more in the lifecycle of a project. 
 

 



Comments

Grant Palin said:

Just read that post - a bit heady but very informative.  I've been using source control for some time, and have more recently learned and integrated automated builds and analysis into one of my projects.  It was somewhat painful trying to get it on after the fact, and I can appreciate it will be much easier to have it in place the next time I start a project.

# May 1, 2008 1:56 PM

Investments on The Finance World For News and Information Around The World On Finance » Blog Archive » Would you do it differently today? said:

Pingback from  Investments on The Finance World For News and Information Around The World On Finance  » Blog Archive   » Would you do it differently today?

# May 1, 2008 5:10 PM

Dew Drop - May 2, 2008 | Alvin Ashcraft's Morning Dew said:

Pingback from  Dew Drop - May 2, 2008 | Alvin Ashcraft's Morning Dew

# May 2, 2008 9:12 AM

Jeff Anderson said:

Jeremy ,

good post,as usual .

While I try to use as many agile techniques as possible on any given project.  I also agree that you need to do some upfront work before you can just jump into development .

Setting up the building testing framework is a good example, but I typically also need to do things like outline the architecture at least a high level (whiteboards, digital cameras and wiki's are often sufficient), get a reasonable understanding of how the business is going to be measuring the success of the project/product (i.e. the business case), and if I am on a large project make sure I understand the dependencies between teams and existing systems being affected, to name a few .

I do make sure to avoid detailed documentation, and focus on getting context necessary to make my agile team successful.

Regards

Jeff

# May 4, 2008 10:38 AM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP