3 ms·

I disagree with the artwork analogy. I think it’s quite easy to decide when a software project is “done” if you set the requirements in detail at the beginning.

I disagree with the artwork analogy. I think it’s quite easy to decide when a software project is “done” if you set the requirements in detail at the beginning. I think the issue plaguing estimation of projects is that a lot of software development involves running into problems and trying to solve them. Sometimes figuring out solutions to these issues is difficult and solutions appear as if by magic (in this was the art analogy makes sense in terms of inspiration). I’m not sure how we can ever estimate large projects accurately while we often need these moments of inspiration in order to solve problems.

CraigJPerry 4y ago
>> if you set the requirements in detail at the beginning How do you do that though? If we’re only talking about nailing down requirements (so lets ignore the problem of dependencies for now), then a 300 page BRD buys you enough spec to gainfully employ 4 devs for maybe a month-ish? I’m going off fin reg style work, i have no idea how that might translate to civil engineering so my numbers might be well off? The BRD wasn’t free to produce, it contains 3-9 errors (assuming human rate of error is 1 to 3 in 100), and it’s being updated to v2 as you’re working. How is this getting us all to the overall goal with predictable timing?