A Day in the Life

A day in my life. Thoughts on leadership, management, startups, technology, software, concurrent development, etc... Basically the stuff I think about from 10am to 6pm.

5/03/2006

Software: Dependable Software Development Schedules

In April I responded to a post on Nima Dilmaghani’s blog entitled "Dependable Software Development Schedules", it was a pretty long response and since I rarely have luck with trackback I’ve included the link and my response here.

Excerpt from Nima’s post:
He talked about the inherent unpredictability of software projects and how the nature of them being creative works makes them unpredictable. He said... < link >

My response:

I disagree with this idea. Software projects can be predicted and there are defined methodologies that can help engineering teams establish real target dates.

When developers miss their dates one of the biggest reasons is because they were not allowed to set the date they wanted. The teams around engineering need to be aware that the developers have a better idea of what they can do and in what time frame, than people who have never written a product. Another big reason for missed dates is feature creep. Experienced engineers will counter a new feature request with, "Well, if we add that then we’ll need to adjust the date x days or drop something. What do you want to do?" Inexperienced engineers will try to fit everything in and consequently miss the target date.

I also think that the newer and less well documented a technology is, the harder it is for engineers to provide a good estimate for the delivery date. For example, if the developer is writing in a new language or with a new SDK, then estimated dates need to be pushed out to accommodate the learning curve and potential product design changes related to those new technologies.

It takes strong engineering leadership to push back on the marketing, product management, and executive teams and say, "No, we can’t meet those dates with those features."

In addition, annual release dates may not be a good decision from a business perspective. Each software vendor must understand their market space because if competitors are moving then so must you. Or if there is a significant market event that requires an update…hitting that could make or break a business. Developers in small software companies have to be responsive to the market because if they aren’t the business will fail and they will soon be looking for work.

And yes I am a developer.

Kim

Anyone have anything to add?

0 Comments:

Post a Comment

<< Home