5 ms·

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. Yo

by 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!
  - andreyvit 15y ago
    > 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? This. One of the biggest sources of uncertainty is not knowing how much of the existing code will work well enough for you.
  - yummyfajitas 15y ago
    If you write your very clear specification down in a formal language, you can simply execute it... This isn't necessarily true. Two examples: for x, y in sorted(lst), assert(x < y => index(x, sorted(lst)) < index(y, sorted(lst)) ) assert( sqrt(x) * sqrt(x) == x ) In more practical terms, at my company we've hired someone to build scrapers for us. They have a fixed interface - scraper.getBrand, scraper.getPrice, etc. The clear specification is that on 100 examples, the scraper needs to agree with humans viewing the webpage (i.e., scraper.getPrice(page) == whatever a human viewing the page says it is).
- nradov 15y ago
  Your "clear" specification is actually quite vague. Can the numbers be integers, floating point, imaginary, or irrational? Are the numbers limited in range or precision? Are there particular requirements for performance, scalability, and hardware resource utilization? You may say I'm being pedantic but these are exactly the type of issues which cause inaccurate estimates.
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.

by toddh 15y ago

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!
- andreyvit 15y ago
  > 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? This. One of the biggest sources of uncertainty is not knowing how much of the existing code will work well enough for you.
- yummyfajitas 15y ago
  If you write your very clear specification down in a formal language, you can simply execute it... This isn't necessarily true. Two examples: for x, y in sorted(lst), assert(x < y => index(x, sorted(lst)) < index(y, sorted(lst)) ) assert( sqrt(x) * sqrt(x) == x ) In more practical terms, at my company we've hired someone to build scrapers for us. They have a fixed interface - scraper.getBrand, scraper.getPrice, etc. The clear specification is that on 100 examples, the scraper needs to agree with humans viewing the webpage (i.e., scraper.getPrice(page) == whatever a human viewing the page says it is).
nradov 15y ago
Your "clear" specification is actually quite vague. Can the numbers be integers, floating point, imaginary, or irrational? Are the numbers limited in range or precision? Are there particular requirements for performance, scalability, and hardware resource utilization? You may say I'm being pedantic but these are exactly the type of issues which cause inaccurate estimates.

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.