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 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 -~----------~----~----~----~------~----~------~--~---