4 ms·

This guy is wrong, and this is an issue of correlation vs. causation. Just because software tends to be something new, and software estimates tend to be off, do

This guy is wrong, and this is an issue of correlation vs. causation. Just because software tends to be something new, and software estimates tend to be off, doesn't mean that things that are new cause estimates to be off. If you give a software developer a very clear specifications of what they need to do, and don't change those specifications, it's very likely that they'll give an accurate estimate and get it done in time. Probably even faster, because most software developers pad their estimates somewhat. Also, it is possible to "invent new things" that have very clear specifications that don't change much. It might not be very common, but it does happen. Especially for relatively simple things. Two things actually cause inaccurate estimates: 1) a lack of clear specifications of what the project is going to be 2) a change in the specifications In many cases, the expense of providing clear specifications is not justified. This is normally the case when companies develop their own products, where they would implement them regardless of how long it would take and bear the expenses themselves. When software development services are provided for other parties, there is normally a "requirements gathering" phase where the developer tries to get a very comprehensive specification for the project. Normally, this specification and its estimates will be very accurate. However, after realizing their mistaken assumptions in the requirements gathering phase, the client tends to want something different from what they wanted before - it is these changes of requirements that cause initial project estimates to be off. In the end, no estimate has to be off if we provide clear specifications - we just have to accept that requirements/specifications are very likely to change during the development of any product.

toddh 15y ago
You've just made the problem one of specification. How do you make clear specifications for something you are in the process of inventing? It's not possible. You'll try to invent it in your head. Early on in implementation what's in your head won't match reality, and it diverges ever more.
- fragsworth 15y ago
  No, you cannot say that every project is impossible to provide clear specifications for. Many projects are simple enough that you can provide accurate estimates for them. Let me give you a trivial example: I want a program that adds three numbers together and appends the string "asdf1234" to the result. 1) I can provide a very clear specification for this. 2) I invented something new. 3) I can provide an accurate estimate for how long it will take to develop. It's not very useful. But there are many "mini-projects" in organizations that are of small enough scale that you can provide accurate estimates and specifications for them. A more complicated, but "useful" example, would be to implement a logging server according to a REST API. The specifications are clear, the project is simple, and the estimate will be very accurate unless the software developer is not very experienced.
  - deleted 15y ago
    [deleted]
  - arijo 15y ago
    What does "implement a logging server according to a REST API" mean? Have you ever coded in your life?
    - jerf 15y ago
      It means that three weeks into your project your realize you fucked up when you required a full HTTP transaction for every log entry, however beautiful the API may have looked during the specification phase, that not even the really fast transactions-per-second web servers are fast enough, and already one week over your carefully crafted perfect time estimate you have to throw everything out and start over again. Yeah, I'm not a big believer in accurate time estimates either. Routinely accurate time estimates imply that you're doing something wrong. If your work is routine enough that you can routinely accurately estimate it, you're missing an automation opportunity somewhere. Probably a big one.
  - kragen 15y ago
    If you write your very clear specification down in a formal language, you can simply execute it: print(($ARGV[0] + $ARGV[1] + $ARGV[2]) . "asdf1234"); The reason you can provide an accurate estimate for how much longer it will take to develop is that, by providing that clear specification, you've already done the development. All that remains is the trivial step of writing it down and invoking a compiler or interpreter. > A more complicated, but "useful" example, would be to implement a logging server according to a REST API. If the REST API in question is well-defined, it's because there's already an implementation of it. Just install that implementation and use it, and you'll be done in half an hour. Are you not sure if you can use the existing implementation? Well, then your project might take 45 minutes, or it might take two weeks. Suddenly you have two orders of magnitude of uncertainty in your estimate. Maybe you know you can't just use the existing implementation; how much of it can you reuse? Is there another piece of software out there that implements the same API? You may be able to get it to work for you in an hour and a half. Or you may be better off writing stuff from scratch. Then, either with the off-the-shelf software or the software you wrote from scratch, you may encounter a killer performance bug — which could take you two weeks to resolve. Or you may not. Maybe you think only the not-very-experienced software developer would consider using off-the-shelf software, or encounter a critical performance bug that could take weeks of work to resolve. If that's what you think, I suspect you're the one who's not very experienced!
- d4nt 15y ago
  Exactly, the fundamentally hard bit of software development is the specification part. As developers we translate between what the customer appears to want and what the compiler requires. If the customer had specified what they want with perfect clarity we would be able to automatically generate code from those requirements (or even compile them directly). But because they haven't been completely clear we have to use judgement and inference.
  - tewolde 15y ago
    This is even a mirror to the development process itself. The most difficult aspect of fixing a bug is identifying it.
elviejo 15y ago
Also if your write a clear specification with several tasks and don't change the specification. And you ask developers what it will take they will "Pad their estimates a little". But the problem is that when they finish early they won't actually finish them they will test a little more, or polish it more etc. Remember Parkinson's Law "Work expands so as to fill the time available for its completion." [1] Now consider student's syndrome "Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline." [2] This two phenomena makes sure that in a project with multiple tasks time saved in a few of them won't be used in the tasks that take more than expected. Based on this Ely Goldratt developed the Critical Chain Project Management methodology [3] [1] http://en.wikipedia.org/wiki/Parkinsons_law http://en.wikipedia.org/wiki/Parkinsons_law [2] http://en.wikipedia.org/wiki/Student_syndrome http://en.wikipedia.org/wiki/Student_syndrome [3] http://en.wikipedia.org/wiki/Critical_Chain http://en.wikipedia.org/wiki/Critical_Chain
tewolde 15y ago
I think semantically we're talking about two sides of the same coin. It's like asking if invention is the answer or the question. I believe it is both in fact probably leaning a bit more on the question side of the equation.
extension 15y ago
Clients can't predict specs for the same reason developers can't predict budgets. Both parties are part of the invention process. They don't know what they want until they use it, you don't know how to build it until you try. And when these things are predictable, it's because they aren't novel. And since software is (ideally) non-repetitive, value fundamentally comes from novelty. In other words, the better you code, the less predictable you will be.

toddh 15y ago

You've just made the problem one of specification. How do you make clear specifications for something you are in the process of inventing? It's not possible. You'll try to invent it in your head. Early on in implementation what's in your head won't match reality, and it diverges ever more.

fragsworth 15y ago
No, you cannot say that every project is impossible to provide clear specifications for. Many projects are simple enough that you can provide accurate estimates for them. Let me give you a trivial example: I want a program that adds three numbers together and appends the string "asdf1234" to the result. 1) I can provide a very clear specification for this. 2) I invented something new. 3) I can provide an accurate estimate for how long it will take to develop. It's not very useful. But there are many "mini-projects" in organizations that are of small enough scale that you can provide accurate estimates and specifications for them. A more complicated, but "useful" example, would be to implement a logging server according to a REST API. The specifications are clear, the project is simple, and the estimate will be very accurate unless the software developer is not very experienced.
- deleted 15y ago
  [deleted]
- arijo 15y ago
  What does "implement a logging server according to a REST API" mean? Have you ever coded in your life?
  - jerf 15y ago
    It means that three weeks into your project your realize you fucked up when you required a full HTTP transaction for every log entry, however beautiful the API may have looked during the specification phase, that not even the really fast transactions-per-second web servers are fast enough, and already one week over your carefully crafted perfect time estimate you have to throw everything out and start over again. Yeah, I'm not a big believer in accurate time estimates either. Routinely accurate time estimates imply that you're doing something wrong. If your work is routine enough that you can routinely accurately estimate it, you're missing an automation opportunity somewhere. Probably a big one.
- kragen 15y ago
  If you write your very clear specification down in a formal language, you can simply execute it: print(($ARGV[0] + $ARGV[1] + $ARGV[2]) . "asdf1234"); The reason you can provide an accurate estimate for how much longer it will take to develop is that, by providing that clear specification, you've already done the development. All that remains is the trivial step of writing it down and invoking a compiler or interpreter. > A more complicated, but "useful" example, would be to implement a logging server according to a REST API. If the REST API in question is well-defined, it's because there's already an implementation of it. Just install that implementation and use it, and you'll be done in half an hour. Are you not sure if you can use the existing implementation? Well, then your project might take 45 minutes, or it might take two weeks. Suddenly you have two orders of magnitude of uncertainty in your estimate. Maybe you know you can't just use the existing implementation; how much of it can you reuse? Is there another piece of software out there that implements the same API? You may be able to get it to work for you in an hour and a half. Or you may be better off writing stuff from scratch. Then, either with the off-the-shelf software or the software you wrote from scratch, you may encounter a killer performance bug — which could take you two weeks to resolve. Or you may not. Maybe you think only the not-very-experienced software developer would consider using off-the-shelf software, or encounter a critical performance bug that could take weeks of work to resolve. If that's what you think, I suspect you're the one who's not very experienced!
d4nt 15y ago
Exactly, the fundamentally hard bit of software development is the specification part. As developers we translate between what the customer appears to want and what the compiler requires. If the customer had specified what they want with perfect clarity we would be able to automatically generate code from those requirements (or even compile them directly). But because they haven't been completely clear we have to use judgement and inference.
- tewolde 15y ago
  This is even a mirror to the development process itself. The most difficult aspect of fixing a bug is identifying it.

elviejo 15y ago

Also if your write a clear specification with several tasks and don't change the specification. And you ask developers what it will take they will "Pad their estimates a little". But the problem is that when they finish early they won't actually finish them they will test a little more, or polish it more etc. Remember Parkinson's Law "Work expands so as to fill the time available for its completion." [1] Now consider student's syndrome "Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline." [2] This two phenomena makes sure that in a project with multiple tasks time saved in a few of them won't be used in the tasks that take more than expected. Based on this Ely Goldratt developed the Critical Chain Project Management methodology [3] [1] http://en.wikipedia.org/wiki/Parkinsons_law http://en.wikipedia.org/wiki/Parkinsons_law [2] http://en.wikipedia.org/wiki/Student_syndrome http://en.wikipedia.org/wiki/Student_syndrome [3] http://en.wikipedia.org/wiki/Critical_Chain http://en.wikipedia.org/wiki/Critical_Chain

tewolde 15y ago

I think semantically we're talking about two sides of the same coin. It's like asking if invention is the answer or the question. I believe it is both in fact probably leaning a bit more on the question side of the equation.

extension 15y ago

Clients can't predict specs for the same reason developers can't predict budgets. Both parties are part of the invention process. They don't know what they want until they use it, you don't know how to build it until you try. And when these things are predictable, it's because they aren't novel. And since software is (ideally) non-repetitive, value fundamentally comes from novelty. In other words, the better you code, the less predictable you will be.