Derek,
I agree with you that the waterfall method of software development is
broken and we don't use it here.
However, we do set deadlines and goals, and we try to make them an
accurate estimation of time required to complete work.
How do we do this? Using a lot of the techniques that you said
above. We never have a deadline that is more than 6 weeks away. It
allows any errors that do get into our timelines to have a minimal
impact. It allows us to be flexible with changing requirements,
and...well, go read an agile development book if you want the rest of
the spiel.
However, I don't even see as much as an "we will have x done in 1
week" in the Django environment. I understand Malcom's arguments
about volunteering and unpredictable development timelines, but to not
even try to shoot for a simple, easy to reach milestone seems like you
are underestimating yourself and your colleagues.
To simply say I don't want to set a milestone just to watch us miss it
ignores that fact that milestones have several benefits:
1) A common, distinct, achievable goal
2) A way to measure progress and learn about weak and strong points in
your development process
3) A tangible accomplishment to make people feel like there is
progress being made
4) Pressure/incentive to complete a task in a timely manner
I don't think the majority of the django core team share my point of
view, so I am willing to accept "it is what it is". I just hope that
my arguments have opened consideration to a few compromises that will
help both the corporate user and the underpaid :) Django commiter.
On Oct 1, 3:05 pm, Derek Anderson <[EMAIL PROTECTED]> wrote:
> actually, "it's done when it's done" can be sold in a corporate
> environment. it has the unfortunate characteristic of being the closest
> thing to truth when modeling software development, and no amount of
> pre-planning or chart-making is going to get you a more accurate answer.
>
> some key facts to present to your management when making your case:
>
> * developers are unable to give unbiased time estimates when they know
> their performance will be judged by comparison to them later
> (it's OK to ask, but never say "but you said...")
> * individual feature deadlines encourage either:
> - slacking because you know you're head of schedule
> - hacking because you know you're behind schedule
> both of which are detrimental to quality and productivity
> * final performance should be judged via post-game analysis (when the
> scope and complexity of a problem are known) and pre-game
> preconceptions should be given little-to-no weight
> * day-by-day performance can be had by monitoring VCS/bugzilla, with no
> performance penalty to the developer. (as long as you enforce
> frequent commits - teach them about temp. branches if they're going
> to be breaking existing functionality for days on end)
>
> and don't say "but my employer/phb is too conservative for this". i've
> run dev teams for telcoms and the us military, two of the most
> hard-nosed waterfall-lovin' organizations ever to have existed. it
> takes a while to prove it right to them, but given persistence without
> dickishness it is possible. (and most PHB's aren't actually evil, just
> confused by the mystical beast that is programming, annoyed at being
> treated like a moron because they don't the the computing equivalent to
> "what's the proper timing sequence for a ford 302 V8", and suspicious of
> programmers who have a history of outright lying to them)
>
> btw, why do you think OSS is beating the pants off of closed-source
> stuff anyway? we don't have more money. we don't have smarter people.
> what we have is a vastly more efficient development model.
>
> anyway, my $.02.
> derek
>
> p.s. btw, it's career suicide just walk in and start with "we're going
> to abandon everything you trust and go with what is described above".
> prerequisites include:
> * building strong trust relationships with your superiors, and making
> sure that when they don't agree with you, they believe you're truly
> arguing in the best interests of the org.
> * proving first that you can make *their* preferred development models
> work, before you try changing them.
> * and don't try to change things wholesale. break them in a piece at a
> time, each time starting with "let's try an experiment"
>
> p.p.s. as far as release dates go, it's ok to set them. just have it
> be known that the deliverable feature set is an always changing target.
> done features are definitely in, in progress features are in flux
> between making the release or the next one. and your unknown factor
> naturally shrinks as you get closer and closer to the date. with
> frequent releases, you'll find the users don't bitch too much when you
> tell them "sorry, X didn't make it into this one because it {'took
> longer','fell to higher priority work'}"
>
> p.p.p.s. still reading? sorry, this turned into a much longer email
> than i anticipated. =p
>
>
>
> Stefan Matthias Aust wrote:
> > Joe,
>
> > 2007/10/1, Joe <[EMAIL PROTECTED]>:
> >> [...]
> >> 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.
> >> [...]
>
> > You explained my points much better than I could (in plain English at least
> > ;)
>
> > Thanks.
>
> --
> looking to buy or sell anything?
>
> try:http://allurstuff.com
>
> it's a classified ads service that
> shows on a map where the seller is
> (think craigslist + google maps)
>
> plus it's 100% free :)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
