7 ms·

Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things an

by jshen 13y ago

Imagine you are a large company and there are 10 ideas for things you can build next, and you can't do them all. You gather the people that build such things and ask them, "how much will it cost to make each of these, and how long will it take". Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." How should a business handle this problem?

aidenn0 13y ago
You can answer with order of magnitude approximations (days, months, years, might be impossible). The order of magnitude approximation is good enough, and for ones in which you can't make an order of magnitude approximation you should be able to back it up. e.g. c.a. 2002 a PMM said "All we need for this idea to work is speaker-independent voice recognition in a noisy environment; how long will that take?" The correct answer to that question isn't a time estimate, or "I don't know" it's saying that doing so is an R&D problem, not an engineering problem.
ebiester 13y ago
I can't give you an exact cost and time, but what I can do is give you relative cost and time. "This is easy, this is easy but will take a while (low variance), this is hard (relatively long time, high variance.) -- so that's giving you your estimate and your tolerances. Further, I can work with you to figure out what portion of each project will give you the biggest bang for your buck. So you can say, "I want to spend x00,000 dollars." -- and I come back and give you a demo each week that you can play around with. At any point, you can say, "This is enough to generate value for me, let's move to the next thing for a while." Further still, I can build it with enough test coverages and good design practices that it will be possible to extend upon the design at a later point without scrapping everything. On the other hand, you can spend half of that x00,000 developing a specification. If detailed enough, I can give you a very low variance estimate of how long it will take. However, you won't know if it will actually meet your needs until you see it. You won't know about problems in what you really need until it's too late, and you'll end up spending more money in the end. That's the message that should go out.
- jshen 13y ago
  Isn't that one of those methodologies ;)
  - greendestiny 13y ago
    Yeah that was a little bit optimistic about the powers of Agile for me, but I think the thing that Agile gets right is that we all have to operate under the uncertainty of the scope of software projects. In that sense it's not a methodology for estimating the complexity of a software project but a way to start working without that. Perhaps the biggest reason this keeps causing problems is that companies have no good way of dealing with change. If you expect to finish any project that you start then you need to know more about that project than is realistic at the time you start it. A canceled project is a big failure for most employees and not something they want to happen to their careers.
    - ebiester 13y ago
      It's not so much avoiding estimating complexity as much as moving from absolute estimates to relative estimates. Arlo Belshee has the best article I've seen on the subject: http://arlobelshee.com/post/planning-with-any-hope-of-accuracy http://arlobelshee.com/post/planning-with-any-hope-of-accura... However, until you establish reality, all the estimates in the world aren't going to help much. And most customers cannot estimate reality until they are actually in the process. I'm not saying Agile is a silver bullet -- it can go wrong in many ways, and it's not appropriate for every situatoin. However, it's the best we have for its niche.
- drewcrawford 13y ago
  You have successfully solved the problem posed, but it was not well-stated. In a real-world scenario, it is important not just to identify which of the 10 ideas is most promising, but to defeat the null hypothesis that the programmers should be fired and no idea should be pursued. After all, to choose the best of 10 bad ideas is to have failed as an economic enterprise. In order for a business to be investable, it is necessary to demonstrate that it will be profitable to an investor. (And of course all businesses need investment, whether that is VC money or just a lone developer's part-time effort.) We have avoided this problem because in the early days of software, most software was profitable. But as the software industry has grown, this is proportionally less true. And I seriously question in 2014 whether more LOC are committed each day to "black" or "red" projects.
jaggederest 13y ago
> Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." If that's the actual answer, then anything else is just obfuscating the truth. Why should we encourage lying to try to cover for the fundamental lack of knowledge? If you don't know, trying to make up numbers never makes things better.
- pekk 13y ago
  Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to. A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally be whoever is at the bottom of the totem pole.
  - robotys 13y ago
    This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody. Managing ego and heart is harder than managing a project i think.
    - gizzlon 13y ago
      The Second Law of Consulting: No matter how it looks at first, it's always a people problem. Gerald Weinberg http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_consulting.2C_1985 http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_... http://www.codinghorror.com/blog/2008/01/no-matter-what-they-tell-you-its-a-people-problem.html http://www.codinghorror.com/blog/2008/01/no-matter-what-they...
      - gizzlon 13y ago
        haha, I love this guy.. Asking for efficiency and adaptability in the same program is like asking for a beautiful and modest wife. Although beauty and modesty have been known to occur in the same woman, we'll probably have to settle for one or the other. At least that's better than neither.
pekk 13y ago
A business should clearly handle this problem by maintaining the delusion that they control all these factors, and firing underlings if they interfere with the maintenance of the delusion.
RamiK 13y ago
Businesses never had the stomach for basic research. It's why progress is traditionally done in one form or another of a governmentally sanctioned monopoly.
invalidOrTaken 13y ago
Beats me. But I have every confidence that you'll figure it out. You're smart, that's why they put you in charge.
raverbashing 13y ago
To know how long something takes you must have done it already. And that's the problem with software, there are no equals. And there are always "surprises". A car manufacturer knows how long it takes to build a car, because it does that thousands of times for a same model. Now, designing the car, that's a different issue. (And don't give me the BS enterprise "model" of architects throwing some UML from a high tower and "developers" filling the voids because that's the worse way you can build a software) Ok, it's one thing to build a simple ACID application, another thing is to build something that "has never been tried before" .
artsrc 13y ago
What about the other half of the uncertainty? The company does not know how much revenue each of those ideas will deliver.
Iftheshoefits 13y ago
The business should handle this "problem" by recognizing it shouldn't be in the business of creating or building new things, because it hasn't got the talent or will "at the top" to understand or stomach all that building or creating new things entails.
scotty79 13y ago
Do you expect to get estimates of outcome from stock market traders? They do their thing and you gain and loose according to external factors. But seriously scrum with concept of velocity and estimating size of tasks is the best approach I've seen. That's if ou want to ask programmere at all. Preferable way would be to predict the duration of the project scientfically from metrics gathered in the past (of not only the programmers and projects but also the environment they operate in). How can a programmer estimate when project will get built if he doesn't even know if anyone actually cares enough about it being built to actually decide what the software should do?

by jshen 13y ago

aidenn0 13y ago

You can answer with order of magnitude approximations (days, months, years, might be impossible). The order of magnitude approximation is good enough, and for ones in which you can't make an order of magnitude approximation you should be able to back it up. e.g. c.a. 2002 a PMM said "All we need for this idea to work is speaker-independent voice recognition in a noisy environment; how long will that take?" The correct answer to that question isn't a time estimate, or "I don't know" it's saying that doing so is an R&D problem, not an engineering problem.

ebiester 13y ago

I can't give you an exact cost and time, but what I can do is give you relative cost and time. "This is easy, this is easy but will take a while (low variance), this is hard (relatively long time, high variance.) -- so that's giving you your estimate and your tolerances. Further, I can work with you to figure out what portion of each project will give you the biggest bang for your buck. So you can say, "I want to spend x00,000 dollars." -- and I come back and give you a demo each week that you can play around with. At any point, you can say, "This is enough to generate value for me, let's move to the next thing for a while." Further still, I can build it with enough test coverages and good design practices that it will be possible to extend upon the design at a later point without scrapping everything. On the other hand, you can spend half of that x00,000 developing a specification. If detailed enough, I can give you a very low variance estimate of how long it will take. However, you won't know if it will actually meet your needs until you see it. You won't know about problems in what you really need until it's too late, and you'll end up spending more money in the end. That's the message that should go out.

jshen 13y ago
Isn't that one of those methodologies ;)
- greendestiny 13y ago
  Yeah that was a little bit optimistic about the powers of Agile for me, but I think the thing that Agile gets right is that we all have to operate under the uncertainty of the scope of software projects. In that sense it's not a methodology for estimating the complexity of a software project but a way to start working without that. Perhaps the biggest reason this keeps causing problems is that companies have no good way of dealing with change. If you expect to finish any project that you start then you need to know more about that project than is realistic at the time you start it. A canceled project is a big failure for most employees and not something they want to happen to their careers.
  - ebiester 13y ago
    It's not so much avoiding estimating complexity as much as moving from absolute estimates to relative estimates. Arlo Belshee has the best article I've seen on the subject: http://arlobelshee.com/post/planning-with-any-hope-of-accuracy http://arlobelshee.com/post/planning-with-any-hope-of-accura... However, until you establish reality, all the estimates in the world aren't going to help much. And most customers cannot estimate reality until they are actually in the process. I'm not saying Agile is a silver bullet -- it can go wrong in many ways, and it's not appropriate for every situatoin. However, it's the best we have for its niche.
drewcrawford 13y ago
You have successfully solved the problem posed, but it was not well-stated. In a real-world scenario, it is important not just to identify which of the 10 ideas is most promising, but to defeat the null hypothesis that the programmers should be fired and no idea should be pursued. After all, to choose the best of 10 bad ideas is to have failed as an economic enterprise. In order for a business to be investable, it is necessary to demonstrate that it will be profitable to an investor. (And of course all businesses need investment, whether that is VC money or just a lone developer's part-time effort.) We have avoided this problem because in the early days of software, most software was profitable. But as the software industry has grown, this is proportionally less true. And I seriously question in 2014 whether more LOC are committed each day to "black" or "red" projects.

jaggederest 13y ago

> Do you think it is an acceptable answer if the builders reply, "I have no idea how much it will cost, I don't know how long it will take, and I don't know what you will have at the end of the process." If that's the actual answer, then anything else is just obfuscating the truth. Why should we encourage lying to try to cover for the fundamental lack of knowledge? If you don't know, trying to make up numbers never makes things better.

pekk 13y ago
Making up numbers doesn't make things better for you or for delivery of the project. But it makes you liable to the boss, so they can make your head roll if they need to. A surprising number of people in business think this way: not that they need to make sure of something, but just that they need someone to tell them everything will be OK, and then put the blame on if anyone is unhappy. That someone will naturally be whoever is at the bottom of the totem pole.
- robotys 13y ago
  This remind me that business is pure gamble, and business people is bad gambler. They want to play but do not want to lose and if they lose they want to blame somebody. Managing ego and heart is harder than managing a project i think.
  - gizzlon 13y ago
    The Second Law of Consulting: No matter how it looks at first, it's always a people problem. Gerald Weinberg http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_consulting.2C_1985 http://en.wikiquote.org/wiki/Gerald_Weinberg#The_secrets_of_... http://www.codinghorror.com/blog/2008/01/no-matter-what-they-tell-you-its-a-people-problem.html http://www.codinghorror.com/blog/2008/01/no-matter-what-they...
    - gizzlon 13y ago
      haha, I love this guy.. Asking for efficiency and adaptability in the same program is like asking for a beautiful and modest wife. Although beauty and modesty have been known to occur in the same woman, we'll probably have to settle for one or the other. At least that's better than neither.

pekk 13y ago

A business should clearly handle this problem by maintaining the delusion that they control all these factors, and firing underlings if they interfere with the maintenance of the delusion.

RamiK 13y ago

Businesses never had the stomach for basic research. It's why progress is traditionally done in one form or another of a governmentally sanctioned monopoly.

invalidOrTaken 13y ago

Beats me. But I have every confidence that you'll figure it out. You're smart, that's why they put you in charge.

raverbashing 13y ago

To know how long something takes you must have done it already. And that's the problem with software, there are no equals. And there are always "surprises". A car manufacturer knows how long it takes to build a car, because it does that thousands of times for a same model. Now, designing the car, that's a different issue. (And don't give me the BS enterprise "model" of architects throwing some UML from a high tower and "developers" filling the voids because that's the worse way you can build a software) Ok, it's one thing to build a simple ACID application, another thing is to build something that "has never been tried before" .

artsrc 13y ago

What about the other half of the uncertainty? The company does not know how much revenue each of those ideas will deliver.

Iftheshoefits 13y ago

The business should handle this "problem" by recognizing it shouldn't be in the business of creating or building new things, because it hasn't got the talent or will "at the top" to understand or stomach all that building or creating new things entails.

scotty79 13y ago

Do you expect to get estimates of outcome from stock market traders? They do their thing and you gain and loose according to external factors. But seriously scrum with concept of velocity and estimating size of tasks is the best approach I've seen. That's if ou want to ask programmere at all. Preferable way would be to predict the duration of the project scientfically from metrics gathered in the past (of not only the programmers and projects but also the environment they operate in). How can a programmer estimate when project will get built if he doesn't even know if anyone actually cares enough about it being built to actually decide what the software should do?