+972 52-548-6969
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.
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
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.
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.
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.
Um, I would disagree.
It is more the fine details that escape me, than the big picture.
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.
Comment preview