Ayende @ Rahien

Refunds available at head office

New project blues

I hate starting new projects.

I realize that this is a fairly uncommon opinion. Most developers that I have met loved going into new projects, starting from a blank slate. I dislike it, because early on in a project, there are all too many things that are still moving. There is a big amount of work that needs to be done before you can see real results.

Here is a typical graph for the time per feature.

image

The first steps are the most frustrating ones. You work for a long while before you can say that you have something that is really worth showing.

Chad Myers calls this Time to Login Screen, I like to think about this as: Time to Business Value, which is just a bit more ambitious.

To add to the burden, I am working with MonoRail after a long hiatus, and I forgot some things and missed other, so I need to ramp up on them again.

Comments

ben
06/13/2008 02:13 AM by
ben

I totally agree.

I've also found in the past couple years that I enjoy maintenance coding more than new projects. It's kind of fun to make big changes to a codebase while still having people use the application.

Bil Simser
06/13/2008 04:43 AM by
Bil Simser

I hear ya. On day 11 of the first sprint of a new project and the first drop to QA is on Monday. Spent the better part of the 11 days working on architecture, tweaking our framework, getting approaches to how we're going to flow through the layers designed, UI starts, login screens. Hopefully next sprint will be a productive one, I don't see a lot of progress from this one.

Tommaso Caldarola
06/13/2008 07:37 AM by
Tommaso Caldarola

If you have forgotten some things then it means MonoRail has some "not natural and fluent" features.

For others framework this has been my impression.

Ayende Rahien
06/13/2008 10:20 AM by
Ayende Rahien

Um, I would disagree.

It is more the fine details that escape me, than the big picture.

Chad Myers
06/13/2008 12:48 PM by
Chad Myers

Ayende,

The Time to Login Screen thing was about bringing in new developers on an existing already-running project. It's purpose is to gauge how well your source control, build automation, code organization, etc are all set up. How easy will it be for a new dev to step into the project and/or a maintenance dev in the future to dust off the old code and start being productive.

Anyhow, this is a good post and worthy of further discussion. This concept you talk about is what killed Jeremy and me at our last job because our boss didn't have the patience or foresight to see the value being created (even if it wasn't necessarily all on the screen just yet).

The proof in the pudding was when LOTS of things started appearing on the screen FAST and they WORKED well, but by then his opinion had already formed and it was too late.

Comments have been closed on this topic.