4 ms·
Lazy thinking. Although deadlines should be avoided as much as possible and should be viewed realistically (shit happens), lots of things that depend upon the s
by onemorepassword 13y ago
Lazy thinking. Although deadlines should be avoided as much as possible and should be viewed realistically (shit happens), lots of things that depend upon the shipped product need to be planned well ahead of time, and can't easily be changed.
Such deadlines aren't there to annoy engineers, they are there because a lot of things need to be coordinated to happen at exactly the same time and place. Software is a means to an end, rarely a goal in itself.
Also, the "it ships when it ships" leads to an attitude in which nothing ships at all. Even if it's no hard deadline, people need a target in which they can frame their effort, especially if it's a joint effort. Nothing is more frustrating than really wanting to get something finished but your coworkers on who your work depends want to do something else. Without a fixed timeframe as a joint reference, it's very hard to stay in sync and make joint progress. I've seen it kill productivity more than unrealistic top-down deadlines.
Finally, there's no excuse for not making the effort to get better at estimating. I've seen well gelled teams play planning poker, give exactly the same estimates independently and hit their targets perfectly. It's not an exact science, but it's not dark magic or wild-ass guesswork either. It's a skill you can hone, especially as a team.
- enraged_camel 13y agoI'll go one step further. Not only are deadlines necessary, but they should be announced to customers and stakeholders. Being able to say, "We are going to release version 2.0 on June 24th, 2013" does a lot of things. First, it signals confidence in your ability to manage your time and resources. Second, it allows your customers to hold you accountable for missed deadlines. Third, it prevents cases where you con yourself out of meeting the deadline with seemingly valid reasons. I refuse to buy products from companies who do not publicize their development roadmap. I'll give games as an example. Back in the day I used to play World of Warcraft, and whenever we asked Blizzard when the next patch or expansion was, they would reply with a flippant and condescending "when it's ready." This was such a common response that players would often use it mockingly and append it with a "TM", because it was a trademark of how Blizzard communicated with its customers. It was one of the main reasons why I canceled my subscription. These days I play Planetside 2, and SOE is a lot better with communication and they go so far as to publish a list of scheduled features and their estimated timeframes. And if schedules change and something gets postponed, they update the list with an explanation of why that happened. As a customer, I want to know what features to expect and when to expect them. Do not try to hide it from me because that will piss me off. The end.
- zinssmeister 13y agowow.
- zenogais 13y agoI also know many Blizzard customers who appreciate that about them because they know the quality won't be abysmal because they rushed to meet a deadline - deadlines and granular communication of roadmaps are less important to them than the quality of their IP.
- enraged_camel 13y agoYou are setting up a false dilemma. Setting deadlines and communicating them to customers do not lower the quality of one's IP.
- zenogais 13y agoThey don't, but they're also not necessary to have a quality IP. They are superfluous.
- enraged_camel 13y agoIt's not about quality of IP. It's about quality of service. They are very different things.
- zenogais 13y agoIf you say so, but I fail to see how the two don't overlap significantly.
- xentronium 13y agoI think they have deadlines internally, but prefer not to publicize them. There seems to be no incentive in doing so. What's better for PR in case of missed deadline, imply that you will only release game when it's good enough, or make apologies? Do you get any reward for non-missed deadline?
- harryf 13y agoDoing product management in this space you have two axes to play on - when you deliver and what you deliver. In general I always find it's best to fix one and vary the other i.e. a) you fix deadlines and you vary on what you ship, sacrificing quality, features etc. to hit a deadline. or b) you fix what you deliver, in terms of functionality, quality etc. and slide your delivery date until it's ready Trouble starts when you're varying on both axes at the same time; mission creep on what you deliver - an ever growing list of features - and no date to force a resolution.