4 ms·

The hard part in estimating a language wouldn't be writing the parser. It would be experimenting with different ideas for the language, which would require tri

by UK-AL 10y ago

The hard part in estimating a language wouldn't be writing the parser. It would be experimenting with different ideas for the language, which would require trial and error and experimentation. That would be hard to estimate. As with most things that programmers do over and over again, creating parsers has been automated. That's the issue with estimation in programming, if you do the same things over and over they get automated. What's left is the unique issues which need to be estimated.

jacques_chester 10y ago
> What's left is the unique issues which need to be estimated. Is it your sincere, genuine contention that 100% of software development is pure research?
- UK-AL 10y ago
  I would not class it as research, but unique problems. Say you are integrating some software into PayPal. Lots of people have integrated PayPal. However no one has integrated your software into PayPal before otherwise you wouldn't be doing it. Your software may have a weird workflow that makes PayPal difficult to integrate. So your going to have figure that out, and that's unique to your software Your software may not have an easy way integrate 3rd party payment providers. So your going to have figure out the best place for those extension points, in reusable way for multiple payment providers. Figuring out those extension points is unique to your software. There will be a lot of unique situations. If however I was using common e-commerce package as opposed to some unique software, I would just install the PayPal add on. no estimation required.
  - jacques_chester 10y ago
    You're right, but it's a categorical argument that doesn't allow for the fact that the world is made of blended probabilities. Strictly speaking, every keystroke is unique. And strictly speaking, I cannot probably show that I exist independently of someone else's perception, or that I'm not in a computer program and so on and so forth. Meanwhile, back in people-need-to-make-decisions land, as an engineer I don't get to just shrug when someone asks me for my professional opinion. I may ask for time to investigate. I may give a wide range due to uncertainty. I may recommend a different approach. I may suggest we bring risky unknowns forward. But ultimately I give my best estimate. If I get it wrong, that's not a sin. Because it's an estimate.
    - UK-AL 10y ago
      I don't mind giving estimates, if they used it as estimates, and people internalise that I may have gotten it badly wrong because something wildly unexpected has happened. In reality though, business try to use estimates to preasure software teams, and punish people who got the estimate wrong.
      - jacques_chester 10y ago
        I think we've come to a similar conclusion. I'm only such a stick in the mud about the topic because I'm lucky to work in a place where estimates are respected as estimates.
        sushiwarrior 10y ago
        You also work in a place where it is not acceptable to be performing a task for the first time, as they are of importance enough to require prior experience, and hence usually do not evolve quickly. Software is constantly changing and software developers are much more likely to completely overhaul a product than a physical design. They will also deal with changing dependencies due to updates and, in things like Javascript land, what way the wind happened to blow that day. Software developers are constantly on adapting and uneven ground for most products which strive to keep very up to date. At places where true software engineering work is required, like mission critical systems, the type of planning that you may be used to will be more common. However even for large companies like Oracle, things like the healthcare site can go wrong [1]. That is just the nature of having to constantly adapt. If things just stayed stagnant, we could get the same level of safety and generations of consistent improvement that things like cars have received, which does happen with maybe Unix or C perhaps. But that does not change the fact that most day-to-day software development is all about hiring someone who knows slightly better than you, but, more importantly, knows how to learn how to get many reasonably new things done which involve parts of what he knows. We don't have the luxury of using safety or danger as a warning, usually. [1]: http://www.bizjournals.com/sanjose/news/2013/12/03/cover-oregon-blasts-oracle-over.html http://www.bizjournals.com/sanjose/news/2013/12/03/cover-ore...

by UK-AL 10y ago

jacques_chester 10y ago

> What's left is the unique issues which need to be estimated. Is it your sincere, genuine contention that 100% of software development is pure research?

UK-AL 10y ago
I would not class it as research, but unique problems. Say you are integrating some software into PayPal. Lots of people have integrated PayPal. However no one has integrated your software into PayPal before otherwise you wouldn't be doing it. Your software may have a weird workflow that makes PayPal difficult to integrate. So your going to have figure that out, and that's unique to your software Your software may not have an easy way integrate 3rd party payment providers. So your going to have figure out the best place for those extension points, in reusable way for multiple payment providers. Figuring out those extension points is unique to your software. There will be a lot of unique situations. If however I was using common e-commerce package as opposed to some unique software, I would just install the PayPal add on. no estimation required.
- jacques_chester 10y ago
  You're right, but it's a categorical argument that doesn't allow for the fact that the world is made of blended probabilities. Strictly speaking, every keystroke is unique. And strictly speaking, I cannot probably show that I exist independently of someone else's perception, or that I'm not in a computer program and so on and so forth. Meanwhile, back in people-need-to-make-decisions land, as an engineer I don't get to just shrug when someone asks me for my professional opinion. I may ask for time to investigate. I may give a wide range due to uncertainty. I may recommend a different approach. I may suggest we bring risky unknowns forward. But ultimately I give my best estimate. If I get it wrong, that's not a sin. Because it's an estimate.
  - UK-AL 10y ago
    I don't mind giving estimates, if they used it as estimates, and people internalise that I may have gotten it badly wrong because something wildly unexpected has happened. In reality though, business try to use estimates to preasure software teams, and punish people who got the estimate wrong.
    - jacques_chester 10y ago
      I think we've come to a similar conclusion. I'm only such a stick in the mud about the topic because I'm lucky to work in a place where estimates are respected as estimates.
      - sushiwarrior 10y ago
        You also work in a place where it is not acceptable to be performing a task for the first time, as they are of importance enough to require prior experience, and hence usually do not evolve quickly. Software is constantly changing and software developers are much more likely to completely overhaul a product than a physical design. They will also deal with changing dependencies due to updates and, in things like Javascript land, what way the wind happened to blow that day. Software developers are constantly on adapting and uneven ground for most products which strive to keep very up to date. At places where true software engineering work is required, like mission critical systems, the type of planning that you may be used to will be more common. However even for large companies like Oracle, things like the healthcare site can go wrong [1]. That is just the nature of having to constantly adapt. If things just stayed stagnant, we could get the same level of safety and generations of consistent improvement that things like cars have received, which does happen with maybe Unix or C perhaps. But that does not change the fact that most day-to-day software development is all about hiring someone who knows slightly better than you, but, more importantly, knows how to learn how to get many reasonably new things done which involve parts of what he knows. We don't have the luxury of using safety or danger as a warning, usually. [1]: http://www.bizjournals.com/sanjose/news/2013/12/03/cover-oregon-blasts-oracle-over.html http://www.bizjournals.com/sanjose/news/2013/12/03/cover-ore...