12 ms·
They set a project delivery date and you just have to hit it. Do you find that this really works out, in practice? Joel has argued[1] that the only schedule wo
by Meekro 11y ago
They set a project delivery date and you just have to hit it.
Do you find that this really works out, in practice? Joel has argued[1] that the only schedule worth anything is the one set by the developers themselves. Management can set relative priorities (X is twice as important as Y), but trying to force a faster deadline on the developers is like trying to make your Linux box run faster by renice-ing every process to -20.
Now, the problem with developer-set schedules is that they tend to underestimate how long things will take. Hence, FogBugz figures out how much each developer underestimates on average, and builds bell curves for the realistic completion time.
[1] http://www.joelonsoftware.com/items/2007/10/26.html http://www.joelonsoftware.com/items/2007/10/26.html
- codeulike 11y agoDo you find that this really works out, in practice? No. Good luck persuading the management to try something else!
- iwwr 11y agoThere may be a niche for enlightened managers or startup funders to promote such a thinking. If successful it will lead to a clear competitive advantage.
- retrogradeorbit 11y agoThis is true. But there is no competitive advantage in going and broadcasting to all your competitors exactly how you achieved the advantage. So the development shops that succeed using this will keep it tight.
- shoo 11y agoRob Thomsett had an article titled "Estimation Games" published in American Programmer, 1996: > It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process. > More importantly, like all good games they are passed on from generation to generation by "children" I.T. people learning from "adult" managers who of course learnt the games from their adults when they were children and so on. Of course, none of the academic institutions [our preschools] prepare the new I.T. graduate for these games but rather, leave it to the cold reality of the work environment to teach graduates [the new children] that estimation techniques are only good for teaching in university. > The good news is that I.T. can estimate better. The bad news is that there are lifetimes of games and refining of games that have to be avoided to do this. There used to be a good copy of it easily visible on the web, today the best I can find for you is this PDF copy of the article: http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F09/files/EstimatingGames.pdf http://research.cs.queensu.ca/~ahmed/home/teaching/CISC322/F... Previous HN discussion (~200 days ago): https://news.ycombinator.com/item?id=9182814 https://news.ycombinator.com/item?id=9182814 Also worth a read for a chuckle: http://www.dadhacker.com/blog/?p=2267 http://www.dadhacker.com/blog/?p=2267
- mtdewcmu 11y agoManagers are the ones that buy this stuff, not developers.
- pinaceae 11y agoabsolutely in enterprise SaaS. beginning with Salesforce.com downwards you have vendors releasing on a fixed schedule. your valve is scope, but even that is fairly fixed as customers drive what needs to get released when (not "stupid" managers).
- shanemhansen 11y agoFrankly the valve is often quality. Quite often something ships on a date. That something is usually crap. In order to get schedule to change, you'd have to convince salespeople to do something. They are generally the ones doing the convincing. In order to get the features to change, you'd have to get a product manager to give up what they want to build "because of technical reasons". That doesn't happen often. But if the product ships with the new features on the agreed upon date, the only people hurt are the developers and the customers. Most people in the business who pretend to care about the customer experience are perfectly happy to do this because it gives them a big club to wield over the engineering team in future iterations.
- nl 11y ago>> They set a project delivery date and you just have to hit it. > Do you find that this really works out, in practice? Of course it works. You just redefine the project (or parts of the project) as you go, shrinking (or occasionally growing) the scope. There's nothing wrong with a fixed delivery date, provided you can adjust scope and/or resources (to some extent) to compensate.
- wpietri 11y agoThat is not my understanding of what most large companies do. Over and over I talk to people who have to deal with fixed dates and fixed scopes. The common outcomes seem to be: 1. Wait until the date is close. Redefine scope in a panic so that success can be declared. 2. Wait until the date has arrived or is past. Have rounds of tears and/or shouting; pick a new date and scope, often as illusory as the first. 3. When the date arrives, ship whatever terrible garbage you happen to have and declare victory. Spend the next N months "fixing bugs", which mostly means "finishing half finished features".
- nl 11y agoI've been in all these situations. The key is to over communicate. When I'm managing a project like that in a situation like that I send an email similar to this: As it currently stands our team will not make the deadline. In order to meet our priorities, I would like to redefine "feature A" to exclude "component Z". This means we will have to do manual work around X. The following alternatives are available: (A) change the deadline, (B) move feature A to next release, (C) remove some other feature". In the absence of any other guidance I'll direct the team to follow the plan above. Happy to discuss further. I've always found this is a pretty effective strategy. Big companies aren't often dumb, you just need to know how to operate in them.
- wpietri 11y agoI think it depends on the company. I've worked inside organizations where that be entirely unacceptable. The date and feature sets are both fixed in advance and are treated as immutable. Nobody would say what you said, but if they did, they'd be on their way out.
- mmatants 11y agoHere's the issue, though - no matter how violently we may agree on the downsides of traditional project management, opinionated tools are just ahead of their time. The market is not at all ready to agree on what software workflow should look like. It just takes time for good techniques to propagate - this is such a young industry... So until there is stable consensus among everyone up to even late adopters about how software work should be managed, any opinion built into the tool will end up being an obstacle for users who are still yet to learn agility the hard way. The real value of an opinionated tool is the opinion itself. And that is something that has to be instilled first. Build a knowledge-base, a following, a community, then make the tool a companion piece.
- overgard 11y agoKinda depends on if it's more important to be on time vs complete. Sometimes hitting a window of time is more important than getting the feature done perfectly, like for an industry event that could build buzz, or a specific holiday season where being late means a lot of lost sales. The worst deadlines are fixed ones for no point, though.
- rukuu001 11y ago> Do you find that this really works out, in practice? We often worked for clients that had media advertising booked and paid for. The product had to be ready. So you make it work. Reduce scope, phase the releases, whatever it takes.