5 ms·

Software projects have an inherent bias towards unpredictability

53 points by stephenjudkins 13y ago

codex 13y ago
I've seen a trend in HN where the comments from a previous story are cherry picked by a third party and turned into a blog post, which is then submitted to HN. It could be coincidence, but it looks like that's what happened here. The counter-argument is that great minds think alike.
- vezzy-fnord 13y ago
  This particular entry looks more like someone just read The Mythical Man-Month and decided to write something about the philosophy of software project management afterwards. Not that it's necessarily bad, but it is formulaic.
- jasonwatkinspdx 13y ago
  I'm the author of the gist. The submitter is a good friend of mine that felt like posting it, and I don't mind. It was a reply I made to another friend and previous co-worker on twitter a while back that was talking about software estimation. It wasn't a comment on any other blog post or hackernews story. I was thinking I should edit and elaborate on it into a full blog post at some point, but that would also require setting up a blog ;P I didn't take the time to write this up to the standards of an adversarial blog aggregation audience. And I don't care to defend it as such or in detail. It's meant to outline a broad point I think is true, but not to be ironclad in it's argument. Anyhow, no cherry picking or anything unethical going on here.
swswsw 13y ago
What the author said is very true. We should accept that there is no good way to estimate the schedule because each software is inherently new. Simply that it will be done when it is done.
- ozim 13y ago
  Like software developers would be some fairies living in mystical land? It is not working that way from other point of view, and that point of view is where money come from ;)
Zigurd 13y ago
Contrast: "You mean you didn't have a complete design for that bridge before you started building it??" "You mean you waterfall designed and implemented your YC app project??"
- deleted 13y ago
  [deleted]
toolslive 13y ago
""" it's likely that adapting old code to a new context is less work than starting from square one again. """ It has been measured that changing more than 25% of software incurs more than 100% of the cost. So your mileage may vary.
- SkyMarshal 13y ago
  Any chance you remember where that measurement came from? I could use that with a client right now, given we're discussing a major refactor of about 25%-30% of the code base.
  - toolslive 13y ago
    It was mentioned in this talk: http://vimeo.com/9270320 http://vimeo.com/9270320 and in the corresponding book "making software" http://shop.oreilly.com/product/9780596808303.do http://shop.oreilly.com/product/9780596808303.do have fun.
    - asabjorn 13y ago
      Have you been able to find the Thomas et al paper that supports this claim? I have been unable to find it, and others seem to have this problem as well: http://www.gdb.me/computing/citations-greg-wilson-cusec.html http://www.gdb.me/computing/citations-greg-wilson-cusec.html
      - toolslive 13y ago
        the slides from the talk are here: http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 (see slide 20) I realized today I got it from somewhere else.. (Facts and fallacies of Software engineering) Looking up the whole reference in that book gave me the title, and googling that gave me the the paper http://drum.lib.umd.edu/bitstream/1903/703/2/CS-TR-3424.pdf http://drum.lib.umd.edu/bitstream/1903/703/2/CS-TR-3424.pdf
- jasonwatkinspdx 13y ago
ams6110 13y ago
True for some projects, not true at all for many others. If you build e-commerce online stores, or other standard sorts of offerings, you may very well be able to "lay the bricks" in a very predictable amount of time after you've done a few.
- jkubicek 13y ago
  Having never worked on an e-commerce store or anything like it, do those sorts of products usually exceed their schedules?
gwu78 13y ago
"Pretty much every piece of technology and algorithm that I use has been known since the 70's and the only thing I do is hook up those technologies in various ways to accomplish a goal. To say that it is "novel" or "unpredictable" is definitely a mischaracterization."
proksoup 13y ago
I dislike doing non-novel things. I dislike being paid for it. If I estimate accurately, it's probably not novel. I dislike accurate estimates. I'll do them, but I'm happy when I do it in 3x the time, not sad. And I certainly don't feel like I wwasted my time. I just can't seem to find any employers or customers who feel the same way.
droid_w 13y ago
Theoretically true, but in practice you see millions of programmers doing "more of the same" and "yet another"

codex 13y ago

I've seen a trend in HN where the comments from a previous story are cherry picked by a third party and turned into a blog post, which is then submitted to HN. It could be coincidence, but it looks like that's what happened here. The counter-argument is that great minds think alike.

vezzy-fnord 13y ago
This particular entry looks more like someone just read The Mythical Man-Month and decided to write something about the philosophy of software project management afterwards. Not that it's necessarily bad, but it is formulaic.
jasonwatkinspdx 13y ago
I'm the author of the gist. The submitter is a good friend of mine that felt like posting it, and I don't mind. It was a reply I made to another friend and previous co-worker on twitter a while back that was talking about software estimation. It wasn't a comment on any other blog post or hackernews story. I was thinking I should edit and elaborate on it into a full blog post at some point, but that would also require setting up a blog ;P I didn't take the time to write this up to the standards of an adversarial blog aggregation audience. And I don't care to defend it as such or in detail. It's meant to outline a broad point I think is true, but not to be ironclad in it's argument. Anyhow, no cherry picking or anything unethical going on here.

swswsw 13y ago

What the author said is very true. We should accept that there is no good way to estimate the schedule because each software is inherently new. Simply that it will be done when it is done.

ozim 13y ago
Like software developers would be some fairies living in mystical land? It is not working that way from other point of view, and that point of view is where money come from ;)

Zigurd 13y ago

Contrast: "You mean you didn't have a complete design for that bridge before you started building it??" "You mean you waterfall designed and implemented your YC app project??"

deleted 13y ago
[deleted]

toolslive 13y ago

""" it's likely that adapting old code to a new context is less work than starting from square one again. """ It has been measured that changing more than 25% of software incurs more than 100% of the cost. So your mileage may vary.

SkyMarshal 13y ago
Any chance you remember where that measurement came from? I could use that with a client right now, given we're discussing a major refactor of about 25%-30% of the code base.
- toolslive 13y ago
  It was mentioned in this talk: http://vimeo.com/9270320 http://vimeo.com/9270320 and in the corresponding book "making software" http://shop.oreilly.com/product/9780596808303.do http://shop.oreilly.com/product/9780596808303.do have fun.
  - asabjorn 13y ago
    Have you been able to find the Thomas et al paper that supports this claim? I have been unable to find it, and others seem to have this problem as well: http://www.gdb.me/computing/citations-greg-wilson-cusec.html http://www.gdb.me/computing/citations-greg-wilson-cusec.html
    - toolslive 13y ago
      the slides from the talk are here: http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 (see slide 20) I realized today I got it from somewhere else.. (Facts and fallacies of Software engineering) Looking up the whole reference in that book gave me the title, and googling that gave me the the paper http://drum.lib.umd.edu/bitstream/1903/703/2/CS-TR-3424.pdf http://drum.lib.umd.edu/bitstream/1903/703/2/CS-TR-3424.pdf
jasonwatkinspdx 13y ago

ams6110 13y ago

True for some projects, not true at all for many others. If you build e-commerce online stores, or other standard sorts of offerings, you may very well be able to "lay the bricks" in a very predictable amount of time after you've done a few.

jkubicek 13y ago
Having never worked on an e-commerce store or anything like it, do those sorts of products usually exceed their schedules?

gwu78 13y ago

"Pretty much every piece of technology and algorithm that I use has been known since the 70's and the only thing I do is hook up those technologies in various ways to accomplish a goal. To say that it is "novel" or "unpredictable" is definitely a mischaracterization."

proksoup 13y ago

I dislike doing non-novel things. I dislike being paid for it. If I estimate accurately, it's probably not novel. I dislike accurate estimates. I'll do them, but I'm happy when I do it in 3x the time, not sad. And I certainly don't feel like I wwasted my time. I just can't seem to find any employers or customers who feel the same way.

droid_w 13y ago

Theoretically true, but in practice you see millions of programmers doing "more of the same" and "yet another"