> I'll pause for a moment here and step out of responding as a Django
> user, and step into responding as Django's release manager: the answer
> is "when it's ready". If you have a foolproof way of figuring out when
> that will be, you should stop writing code and start making millions
> of dollars selling your secret to businesses which develop software.

In the business world, we set goals and track our progress to them.
In the act of tracking our goals, we learn lessons that improve our
development processes and increase our productivity.  Django's team
can do the same.  Set a goal, even if it is "Let's shoot to make the
trunk stable on 10/10 so we can tag the code."

> "It's done when it's done" is all I can give you. "It's done even
> though it's not" wouldn't make any sense, and neither would automatic
> releases; I'll take quality over quantity any day of the week, and
> "released later, but finished" over "released now, but doesn't work".

And this is the biggest disconnect between Django's team and the
business world.  If I went to my bosses and told them "It's done when
it's done" about our upcoming product releases, I would get fired.
Your response should be, "It's really hard to estimate, but here is my
best guess and a target for us to shoot for."  And, you know what?
Most of the time our estimates are pretty close.  And by tracking how
we do on our estimates, we can make them even more accurate.

> Personally, I look on timelines and roadmaps as lies dressed up in
> fancy clothing. When Fred Brooks wrote his famous book on software
> management, nobody really had a handle on how to plan or schedule
> software projects. Thirty-two years later, nobody really has a handle
> on how to plan or schedule software projects.

I disagree.  There are ways to plan and manage software development
and to minimize risk.  Build in padding time for disasters.  Don't set
one big goal, set a bunch of little ones.  Update your plan when
things don't go as planned.

Start simple.  Shoot to have a stable trunk on a certain date.

And, I already know your going to say this:

> Generally, the Django team works to keep trunk as stable as possible;

If this is true, what is the disadvantage to tagging a release every
couple of months?  It would provide a serious benefit to those of us
who have to deal with corporate red tape.

I know this may seem a little harsh and may get your blood stirred up,
but I ask you to consider it rationally as a way to help us project
managers with restrictive corporate oversight.

Regards,

Joe


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to