3 ms·

>> If I am running a business that is looking at what projects to fund for the next year, and one of those projects is a software project with an unknowable tim

by markbnj 10y ago

>> If I am running a business that is looking at what projects to fund for the next year, and one of those projects is a software project with an unknowable time to completion vs (for example) opening a new store, with a well known time to complete, why would I ever pick the software project? Maybe because you're trying to innovate? Will opening a new store dramatically change your company's market outlook? Will it open up entirely new markets for products you don't yet have? Will it solve new problems for people? Milton Hershey offered his first chocolate bar in 1900. It took him a further five years to perfect the manufacturing processes that produced the Hershey's Kiss. None of those processes, and none of the machinery to execute them existed when he started. He had to invent them. Today, 110 or so years later, the company produces around 60 million of them a day which it ships all over the world. Probably he should have just opened another store. No offense, but people who think the way you do about risk are exactly the reason large companies lose their ability to innovate at all.

lj3 10y ago
> Maybe because you're trying to innovate? > No offense, but people who think the way you do about risk are exactly the reason large companies lose their ability to innovate at all. Exactly. This is why the startup ecosystem continues to thrive even after the age of the big IPO is over. Startups are akin to R&D for larger companies who don't want to (or can't) take the risk to try something new.
cpitman 10y ago
I'm not really making the argument your reacting to. Software projects can be estimated, so it is possible to understand what their ROI is. I'm saying that, because software can be estimated using rigorous technique instead of hunches, that we can continue to justify developing software. Even if what you are doing is truly research that is completely open ended, there still have to be controls placed on it. Budget/grants/runway will run out at some point.
- maxaf 10y ago
  I'm not a believer in what you're saying, but I dearly want to believe, in no small part because there are significant organizational rewards to be reaped for believing in estimates and acting the part. What are these rigorous techniques you speak of? I seriously, honestly want to know.
  - cpitman 10y ago
    The book I linked up above is one of the best I've read on software estimation. It's short, it covers exactly the problems we run into everyday (managers take estimates to mean commitments, optimism on most estimates, constant pressure to reduce estimates because they cannot be defended, etc). And it covers several different estimation methods that you can choose from based on circumstances, the pros and cons of each, etc. It's "Software Estimation: Demystifying the Black Art" by Steve McConnell (https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDMPOVQ&preview=newtab&linkCode=kpe&ref_=cm_sw_r_kb_dp_kE5KxbAPDNJB5 https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDM...). Same author as "Code Complete" and "Rapid Development", which are also great books but much longer and showing their age a little more.
    - maxaf 10y ago
      Thanks! I'm going to give it a read.
  - HeyLaughingBoy 10y ago
    First, I second (heh!) his book recommendation. Second, in estimation, previous performance is often indicative of future performance. If something took you X days before, it will likely take you roughly X days next year. It's not likely to take 10X the time. The real problem is that very few teams actually track their time on task accurately so no one on the team knows what X was. Without that data, trying to get accurate estimates is a waste of time. A very large part of the problem is that most developers are educated in Computer Science or other areas and simply haven't been trained in estimation techniques. Software Engineering is about the process side of development, and one of the benefits of process is predictability.
- markbnj 10y ago
  >> Software projects can be estimated Managers, for the most part, keep saying that. Usually its because they have, or they've read about someone who has estimated accurately one or more times. How do I know they were not simply lucky? We cannot accurately estimate the time it will take to construct a building, and we've been constructing buildings for thousands of years.

by markbnj 10y ago

lj3 10y ago

> Maybe because you're trying to innovate? > No offense, but people who think the way you do about risk are exactly the reason large companies lose their ability to innovate at all. Exactly. This is why the startup ecosystem continues to thrive even after the age of the big IPO is over. Startups are akin to R&D for larger companies who don't want to (or can't) take the risk to try something new.

cpitman 10y ago

I'm not really making the argument your reacting to. Software projects can be estimated, so it is possible to understand what their ROI is. I'm saying that, because software can be estimated using rigorous technique instead of hunches, that we can continue to justify developing software. Even if what you are doing is truly research that is completely open ended, there still have to be controls placed on it. Budget/grants/runway will run out at some point.

maxaf 10y ago
I'm not a believer in what you're saying, but I dearly want to believe, in no small part because there are significant organizational rewards to be reaped for believing in estimates and acting the part. What are these rigorous techniques you speak of? I seriously, honestly want to know.
- cpitman 10y ago
  The book I linked up above is one of the best I've read on software estimation. It's short, it covers exactly the problems we run into everyday (managers take estimates to mean commitments, optimism on most estimates, constant pressure to reduce estimates because they cannot be defended, etc). And it covers several different estimation methods that you can choose from based on circumstances, the pros and cons of each, etc. It's "Software Estimation: Demystifying the Black Art" by Steve McConnell (https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDMPOVQ&preview=newtab&linkCode=kpe&ref_=cm_sw_r_kb_dp_kE5KxbAPDNJB5 https://read.amazon.com/kp/embed?asin=B00JDMPOVQ&asin=B00JDM...). Same author as "Code Complete" and "Rapid Development", which are also great books but much longer and showing their age a little more.
  - maxaf 10y ago
    Thanks! I'm going to give it a read.
- HeyLaughingBoy 10y ago
  First, I second (heh!) his book recommendation. Second, in estimation, previous performance is often indicative of future performance. If something took you X days before, it will likely take you roughly X days next year. It's not likely to take 10X the time. The real problem is that very few teams actually track their time on task accurately so no one on the team knows what X was. Without that data, trying to get accurate estimates is a waste of time. A very large part of the problem is that most developers are educated in Computer Science or other areas and simply haven't been trained in estimation techniques. Software Engineering is about the process side of development, and one of the benefits of process is predictability.
markbnj 10y ago
>> Software projects can be estimated Managers, for the most part, keep saying that. Usually its because they have, or they've read about someone who has estimated accurately one or more times. How do I know they were not simply lucky? We cannot accurately estimate the time it will take to construct a building, and we've been constructing buildings for thousands of years.