7 ms·

It ships when it ships

59 points by zinssmeister 14y ago

zalew 14y ago
> Not sure who started these artificial deadlines for things Closest to home, I'd guess the advertising industry, where although highly abused, deadlines exist for a reason. Nevertheless deadlines are a disease spread mostly through cargo-culting.
parsnips 14y ago
"Artificial Deadlines" are typically tied to some sales or marketing cycle. (ie We're announcing the launch of product ACME WidgetFoo at FooConf2013.) If you're truly a member of a "team" (one that includes the positions of Marketing and Sales), hard deadlines are simply a fact that cannot be avoided (unless say, you're Apple Inc). The key is for everyone to understand the difference between aspirational goals, and deliverable goals for the deadline. If you're fighting this battle constantly, I'd take that as a sign that you're not a player on the team. Ball boy.
- stevedt 14y ago
  More generally, when you are coordinating activity with others. If the code being deployed requires announcements to users, Help Desk people, changes to other applications, changes do documentation, etc., then these are not "artificial" at all.
  - parsnips 14y ago
    Well put. It's all about context. Understanding your role and how to influence the result is part of the "game". You do not escape the "game" by being good at coding most times.
stevenameyer 14y ago
The one thing I would give as a benefit to setting a deadline is that it can help prevent feature creep for a specific version.[0] The amount of times that I have had a manager come to me just prior to a version being ready to ship and ask me to squeeze a new feature into this release is staggering. This is where being able to push back with "not if we are going to hit the release date." really helps. Now ideally you are able to agree on what to put in each release and stick to it, but a lot of work places are not ideal and feature creep can be a huge issue which can easily be addressed by implementing a release schedule and sticking to it (for the most part). [0]This is more applicable to areas such as mobile where it is unrealistic to ship releases every week.
- zinssmeister 14y ago
  feature creep would be a good topic for another blog post some day... met many of those.
opcenter 14y ago
My boss is pretty cool about this. He asks for estimates on tasks for resource management purposes, but he assumes the estimates are wrong out of the gate and we adjust as the project progresses. So, I agree that focusing on an arbitrary deadline is foolish, but drawing a line in the sand can help keep people on task.
- zinssmeister 14y ago
  yeah I think a Goal can be to "try" and release something by the end of the month but making that a hard deadline puts unnecessary stress on a team.
  - nowarninglabel 14y ago
    So I believe you are wrong on thinking it is unnecessary stress, based upon some research done by Dan Ariely on students getting their work done with and without deadlines. You have to read his book Predictably Irrational for the full story, but here's a synopsis: http://danariely.com/2010/08/30/back-to-school-2/ http://danariely.com/2010/08/30/back-to-school-2/ Long story short is that without deadlines people tend to push off work to the latest possible moment, at which point they tend not to be able to do as much as they thought they could in that short time space, so it actually causes more stresses on them than it would have to have had a series of deadlines along the way.
    - zinssmeister 14y ago
      Interesting thoughts on procrastination. Comparing a software developer that has passion for his craft with some high school student is probably not the right approach though either...
      - nowarninglabel 14y ago
        College students actually. And I'd agree somewhat, although I'd say you could easily extrapolate it to newly hired developers fresh out of college, and that it may be extensible beyond that. Either way, research points against your conclusion and you have no factual basis for it, so it'd be good to find some support. Edit: Here's some more research which backs up why your conclusion may not be correct: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3374478/ http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3374478/ Granted it is probably too early in the research of this area to say your conclusions are wrong, just that the research is leaning that way
bjxrn 14y ago
"But is this even a real problem? No, not really." If you have that luxury then that's great. For you. But if you're doing client work you likely don't have the luxury of never having to estimate. And even if you're not doing client work then it would likely be a good idea to at least give it a passing consideration. Say you have a client who wants [x] and it needs to be done by a certain date (Yes! This does happen!), then it is helpful for you to know whether or not you might be able to deliver. Say you have a client who wants [x] for [money]. Then it is helpful for you to know whether or not you might be able to produce it in a time frame which makes sense economically. Say you have two ways of solving a certain problem. Then it is helpful for you to know if one solution would take a week and the other a year. Estimation can be hard, sometimes impossible. But I'm not sure pretending it's not a problem is a viable solution for many.
far33d 14y ago
It ships when it ships is a great mantra for someone working on something in a vacuum. Marketing, sales, demos, meetings, running out of cash, press embargoes, and a host of other reasons can create real deadlines whether you like it or not. Plans and deadlines are also helpful as a measure of progress - are we ahead or behind what we planned?
- nvk 14y ago
  Can't agree more, this is a great mantra for someone not having to pay the businesses bills.
- bobdvb 14y ago
  Agreed, we need to get advertising booked months in advance, we need to source materials 16 weeks in advance, book production two months, etc. If you aren't dealing in serious marketing and tangible products then you can release whenever you like!
onemorepassword 14y 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 14y ago
  I'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.
suhastech 14y ago
I know, no one can accurately estimate timelines. As an independent developer, I crave for a deadline (like a conference) and let parkinson's law[1] do it's thing. [1]http://en.wikipedia.org/wiki/Parkinsons_law http://en.wikipedia.org/wiki/Parkinsons_law
bluedino 14y ago
Try closing a deal with a customer and saying that. You'll have the app delivered when? When we're done with it. Mobile support is going to be added when? When we're done with it. ... "When it's done" works great when you can keep the product mysterious or you don't have anyone using it. But not when you have real-world deadlines.
btilly 14y ago
When you're presented with a deadline, the first question that you should ask is what type of deadline you have. Here are some common possibilities: - A number to use to whip people to work harder. (Yes, despite much research demonstrating how counterproductive that is for developers, a lot of management teams still try it. In part because big audacious goals tend to work well in other fields, like marketing.) - A hard date that must be met. You need something to announce at a conference. A new tax law is in place. And so on. - A date for the rest of the company knows what to plan around. How you should treat a deadline varies by the type. If it is one that exists to whip you, ignore it as you file your resume looking for somewhere better. If it exists because something needs to be done, you should work hard to make sure that there will be a minimum viable product available before that date, then improve it as much as it can be improved for that date. If it exists for planning purposes, then make sure it has sufficient padding, and develop as efficiently as you can. And so on. Now that you know what kind of deadline you have, where did it come from? In most organizations, the schedule estimate arrives as the first date that nobody can disprove. That is why software usually takes about 2x as long to deliver (if it ever is delivered) as it was estimated. But research indicates that, for software developers, the more confidence that they have in the schedule, the more productive they are. Many have noticed that when developers work to a schedule estimate that they produced, developers are more productive than if it is a schedule made up by management. However if developers work to a schedule estimate produced by an expert estimator, productivity goes up again. Most organizations do not have expert estimators. So involve developers in schedule estimation. Add in fudge factors for sick time, unplanned obstacles, etc. As a good approximation the ratio between past plans and past performance is a good ratio to apply. As the project goes on, if the schedule starts to slip, immediately assume that all later parts will slip by the same ratio that you're experiencing already. To be able to catch slips, you need unambiguous milestones that can't be fudged. Otherwise people will say things like, "Coding is 90% complete" having pushed off the hard 10% that will take as long as what is done. And if you want more good advice, I highly recommend Steve McConnell's Software Estimation. (You could substitute most of his books for that one, and the recommendation would stand. But that's the one on estimating schedules.)
- zinssmeister 14y ago
ttrreeww 14y ago
We got a winner. The previous place I've been was like estimate estimate, guess what, they never ship anything compared to a startup that does no estimates.
- avelis 14y ago
  This tends to happen when a startup has nothing to lose and everything to gain. If you have a team that has a shared goal and understood roles they can be productive.
  - ttrreeww 14y ago
    What happened was, we shipped estimates, instead of shipping what the customer wants. Estimates makes you lose the forest for the wrong trees.
unoti 14y ago
Deadlines are not artificial. If you screw around long enough, various real world things happen, such as your competition leaving you in the dust, your product becoming irrelevant, customers not caring any more whether the problem is fixed because they've gone to a competitor. There are engineering realities, such as it won't be fixed until it's fixed. But there are business realities, too. A formative moment for me was when I was the software manager for a company, and we had two clients with emergencies going on at the same time. The reality was, we couldn't really fix both problems at the same time. I went in to the president's office, and told her that we couldn't fix both problems right now, and I needed her to decide which client was going to suffer. She yelled at me, told me to get the hell out of her office, and figure out a solution that doesn't force either client to be the loser. I fumed and left, she obviously didn't understand the reality. But once I finished pouting, I realized there was a way I could implement a temporary fix for one real quick, and then work on the other... There are business realities, and there are engineering realities. A business needs to manage both to deliver something awesome, or get overtaken by somebody else that will.
- zinssmeister 14y ago
  "If you screw around long enough", that is the real problem. Just don't screw around.
rogerbinns 14y ago
I always give a range with my estimates. The range is due to risks like current unknowns, probability of bugs due to interaction with other components, additional work that will possibly need to be done, documentation complexity, technical debt in related pieces etc. Sometimes those can be rather extreme so my estimates have been "one month, plus/minus three months". If four months is acceptable then everyone is happy and as progress is made the range narrows. If time is tight then the discussion turns to reducing the range which puts everyone on the same page.
chasing 14y ago
If you're playing a soccer game and you're down a point and there are five minutes left in the game... there's a deadline.
- avelis 14y ago
  I believe that he pointed it out as a valid scenario of a goal becoming a deadline by the constraint of time. Otherwise it was trying to have a sound strategy/goal to ensure winning the game. There is many ways to interpret the posted article.
  - epidemian 14y ago
    Yep. I thought the football analogy was pretty good though. Many times i've worked for people that were only good at communicating the (always urgent) deadlines but not the overall objective of the product we were making, which was in no way very motivating or engaging. I think this is probably one reason for the low job retention we experience in this field.
wubbfindel 14y ago
Another thing to consider, if you're doing client work and you charge per hour; the deadline is also when the agreed budget runs out. If you haven't finished by the agreed deadline you may have to get approval for extra spending. You can't really have an open deadline, and just charge whatever when you eventually finish.
- aidenn0 14y ago
  > You can't really have an open deadline, and just charge whatever when you eventually finish. http://en.wikipedia.org/wiki/Cost-plus_contract http://en.wikipedia.org/wiki/Cost-plus_contract
taytus 14y ago
The soccer analogy fails because there is nothing else to coordinate besides scoring a goal. When you work for a company there are so many other areas waiting for that feature or release you just can't say something like that, I'm afraid.
avelis 14y ago
To further this conversation I think it's important to discuss continuous deployment or even shipping velocity that is both robust, lean, and efficient. Consider this: If software, at a given state, is ready for consumption how long does it take until it is actually consumed and why is it that long? Could it be shorter? Could it be longer? Does it ever get consumed?
woodchuck64 14y ago
Loved that simile: setting an artificial deadline is like setting when your team will score its next goal in a soccer game.
- aidenn0 14y ago
  A non-artificial deadline is saying "If we want to win, we need to scare at least one goal in the next 90 minutes of playtime"

59 points by zinssmeister 14y ago

zalew 14y ago

> Not sure who started these artificial deadlines for things Closest to home, I'd guess the advertising industry, where although highly abused, deadlines exist for a reason. Nevertheless deadlines are a disease spread mostly through cargo-culting.

parsnips 14y ago

"Artificial Deadlines" are typically tied to some sales or marketing cycle. (ie We're announcing the launch of product ACME WidgetFoo at FooConf2013.) If you're truly a member of a "team" (one that includes the positions of Marketing and Sales), hard deadlines are simply a fact that cannot be avoided (unless say, you're Apple Inc). The key is for everyone to understand the difference between aspirational goals, and deliverable goals for the deadline. If you're fighting this battle constantly, I'd take that as a sign that you're not a player on the team. Ball boy.

stevedt 14y ago
More generally, when you are coordinating activity with others. If the code being deployed requires announcements to users, Help Desk people, changes to other applications, changes do documentation, etc., then these are not "artificial" at all.
- parsnips 14y ago
  Well put. It's all about context. Understanding your role and how to influence the result is part of the "game". You do not escape the "game" by being good at coding most times.

stevenameyer 14y ago

The one thing I would give as a benefit to setting a deadline is that it can help prevent feature creep for a specific version.[0] The amount of times that I have had a manager come to me just prior to a version being ready to ship and ask me to squeeze a new feature into this release is staggering. This is where being able to push back with "not if we are going to hit the release date." really helps. Now ideally you are able to agree on what to put in each release and stick to it, but a lot of work places are not ideal and feature creep can be a huge issue which can easily be addressed by implementing a release schedule and sticking to it (for the most part). [0]This is more applicable to areas such as mobile where it is unrealistic to ship releases every week.

zinssmeister 14y ago
feature creep would be a good topic for another blog post some day... met many of those.

opcenter 14y ago

My boss is pretty cool about this. He asks for estimates on tasks for resource management purposes, but he assumes the estimates are wrong out of the gate and we adjust as the project progresses. So, I agree that focusing on an arbitrary deadline is foolish, but drawing a line in the sand can help keep people on task.

zinssmeister 14y ago
yeah I think a Goal can be to "try" and release something by the end of the month but making that a hard deadline puts unnecessary stress on a team.
- nowarninglabel 14y ago
  So I believe you are wrong on thinking it is unnecessary stress, based upon some research done by Dan Ariely on students getting their work done with and without deadlines. You have to read his book Predictably Irrational for the full story, but here's a synopsis: http://danariely.com/2010/08/30/back-to-school-2/ http://danariely.com/2010/08/30/back-to-school-2/ Long story short is that without deadlines people tend to push off work to the latest possible moment, at which point they tend not to be able to do as much as they thought they could in that short time space, so it actually causes more stresses on them than it would have to have had a series of deadlines along the way.
  - zinssmeister 14y ago
    Interesting thoughts on procrastination. Comparing a software developer that has passion for his craft with some high school student is probably not the right approach though either...
    - nowarninglabel 14y ago
      College students actually. And I'd agree somewhat, although I'd say you could easily extrapolate it to newly hired developers fresh out of college, and that it may be extensible beyond that. Either way, research points against your conclusion and you have no factual basis for it, so it'd be good to find some support. Edit: Here's some more research which backs up why your conclusion may not be correct: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3374478/ http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3374478/ Granted it is probably too early in the research of this area to say your conclusions are wrong, just that the research is leaning that way

bjxrn 14y ago

"But is this even a real problem? No, not really." If you have that luxury then that's great. For you. But if you're doing client work you likely don't have the luxury of never having to estimate. And even if you're not doing client work then it would likely be a good idea to at least give it a passing consideration. Say you have a client who wants [x] and it needs to be done by a certain date (Yes! This does happen!), then it is helpful for you to know whether or not you might be able to deliver. Say you have a client who wants [x] for [money]. Then it is helpful for you to know whether or not you might be able to produce it in a time frame which makes sense economically. Say you have two ways of solving a certain problem. Then it is helpful for you to know if one solution would take a week and the other a year. Estimation can be hard, sometimes impossible. But I'm not sure pretending it's not a problem is a viable solution for many.

far33d 14y ago

It ships when it ships is a great mantra for someone working on something in a vacuum. Marketing, sales, demos, meetings, running out of cash, press embargoes, and a host of other reasons can create real deadlines whether you like it or not. Plans and deadlines are also helpful as a measure of progress - are we ahead or behind what we planned?

nvk 14y ago
Can't agree more, this is a great mantra for someone not having to pay the businesses bills.
bobdvb 14y ago
Agreed, we need to get advertising booked months in advance, we need to source materials 16 weeks in advance, book production two months, etc. If you aren't dealing in serious marketing and tangible products then you can release whenever you like!

onemorepassword 14y 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 14y ago
I'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.

suhastech 14y ago

I know, no one can accurately estimate timelines. As an independent developer, I crave for a deadline (like a conference) and let parkinson's law[1] do it's thing. [1]http://en.wikipedia.org/wiki/Parkinsons_law http://en.wikipedia.org/wiki/Parkinsons_law

bluedino 14y ago

Try closing a deal with a customer and saying that. You'll have the app delivered when? When we're done with it. Mobile support is going to be added when? When we're done with it. ... "When it's done" works great when you can keep the product mysterious or you don't have anyone using it. But not when you have real-world deadlines.

btilly 14y ago

When you're presented with a deadline, the first question that you should ask is what type of deadline you have. Here are some common possibilities: - A number to use to whip people to work harder. (Yes, despite much research demonstrating how counterproductive that is for developers, a lot of management teams still try it. In part because big audacious goals tend to work well in other fields, like marketing.) - A hard date that must be met. You need something to announce at a conference. A new tax law is in place. And so on. - A date for the rest of the company knows what to plan around. How you should treat a deadline varies by the type. If it is one that exists to whip you, ignore it as you file your resume looking for somewhere better. If it exists because something needs to be done, you should work hard to make sure that there will be a minimum viable product available before that date, then improve it as much as it can be improved for that date. If it exists for planning purposes, then make sure it has sufficient padding, and develop as efficiently as you can. And so on. Now that you know what kind of deadline you have, where did it come from? In most organizations, the schedule estimate arrives as the first date that nobody can disprove. That is why software usually takes about 2x as long to deliver (if it ever is delivered) as it was estimated. But research indicates that, for software developers, the more confidence that they have in the schedule, the more productive they are. Many have noticed that when developers work to a schedule estimate that they produced, developers are more productive than if it is a schedule made up by management. However if developers work to a schedule estimate produced by an expert estimator, productivity goes up again. Most organizations do not have expert estimators. So involve developers in schedule estimation. Add in fudge factors for sick time, unplanned obstacles, etc. As a good approximation the ratio between past plans and past performance is a good ratio to apply. As the project goes on, if the schedule starts to slip, immediately assume that all later parts will slip by the same ratio that you're experiencing already. To be able to catch slips, you need unambiguous milestones that can't be fudged. Otherwise people will say things like, "Coding is 90% complete" having pushed off the hard 10% that will take as long as what is done. And if you want more good advice, I highly recommend Steve McConnell's Software Estimation. (You could substitute most of his books for that one, and the recommendation would stand. But that's the one on estimating schedules.)

zinssmeister 14y ago

ttrreeww 14y ago

We got a winner. The previous place I've been was like estimate estimate, guess what, they never ship anything compared to a startup that does no estimates.

avelis 14y ago
This tends to happen when a startup has nothing to lose and everything to gain. If you have a team that has a shared goal and understood roles they can be productive.
- ttrreeww 14y ago
  What happened was, we shipped estimates, instead of shipping what the customer wants. Estimates makes you lose the forest for the wrong trees.

unoti 14y ago

Deadlines are not artificial. If you screw around long enough, various real world things happen, such as your competition leaving you in the dust, your product becoming irrelevant, customers not caring any more whether the problem is fixed because they've gone to a competitor. There are engineering realities, such as it won't be fixed until it's fixed. But there are business realities, too. A formative moment for me was when I was the software manager for a company, and we had two clients with emergencies going on at the same time. The reality was, we couldn't really fix both problems at the same time. I went in to the president's office, and told her that we couldn't fix both problems right now, and I needed her to decide which client was going to suffer. She yelled at me, told me to get the hell out of her office, and figure out a solution that doesn't force either client to be the loser. I fumed and left, she obviously didn't understand the reality. But once I finished pouting, I realized there was a way I could implement a temporary fix for one real quick, and then work on the other... There are business realities, and there are engineering realities. A business needs to manage both to deliver something awesome, or get overtaken by somebody else that will.

zinssmeister 14y ago
"If you screw around long enough", that is the real problem. Just don't screw around.

rogerbinns 14y ago

I always give a range with my estimates. The range is due to risks like current unknowns, probability of bugs due to interaction with other components, additional work that will possibly need to be done, documentation complexity, technical debt in related pieces etc. Sometimes those can be rather extreme so my estimates have been "one month, plus/minus three months". If four months is acceptable then everyone is happy and as progress is made the range narrows. If time is tight then the discussion turns to reducing the range which puts everyone on the same page.

chasing 14y ago

If you're playing a soccer game and you're down a point and there are five minutes left in the game... there's a deadline.

avelis 14y ago
I believe that he pointed it out as a valid scenario of a goal becoming a deadline by the constraint of time. Otherwise it was trying to have a sound strategy/goal to ensure winning the game. There is many ways to interpret the posted article.
- epidemian 14y ago
  Yep. I thought the football analogy was pretty good though. Many times i've worked for people that were only good at communicating the (always urgent) deadlines but not the overall objective of the product we were making, which was in no way very motivating or engaging. I think this is probably one reason for the low job retention we experience in this field.

wubbfindel 14y ago

Another thing to consider, if you're doing client work and you charge per hour; the deadline is also when the agreed budget runs out. If you haven't finished by the agreed deadline you may have to get approval for extra spending. You can't really have an open deadline, and just charge whatever when you eventually finish.

aidenn0 14y ago
> You can't really have an open deadline, and just charge whatever when you eventually finish. http://en.wikipedia.org/wiki/Cost-plus_contract http://en.wikipedia.org/wiki/Cost-plus_contract

taytus 14y ago

The soccer analogy fails because there is nothing else to coordinate besides scoring a goal. When you work for a company there are so many other areas waiting for that feature or release you just can't say something like that, I'm afraid.

avelis 14y ago

To further this conversation I think it's important to discuss continuous deployment or even shipping velocity that is both robust, lean, and efficient. Consider this: If software, at a given state, is ready for consumption how long does it take until it is actually consumed and why is it that long? Could it be shorter? Could it be longer? Does it ever get consumed?

woodchuck64 14y ago

Loved that simile: setting an artificial deadline is like setting when your team will score its next goal in a soccer game.

aidenn0 14y ago
A non-artificial deadline is saying "If we want to win, we need to scare at least one goal in the next 90 minutes of playtime"