6 ms·

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 on

by 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...
      - jacques_chester 10y ago
        Given that Pivotal wrote and then donated ownership of an entire containerised cloud platform, built from scratch, before any of Mesos, Kubernetes or Docker existed, I feel like we've done some fairly heavy original engineering. We estimate every story. Sometimes hilariously wrong (Diego was a classic example of a research-heavy project blasting past the initial gut-check estimates and improving in accuracy as it matured). But a lot of the time well enough to allow for useful business decisions to be made by ourselves and other members of the Cloud Foundry Foundation. The reason that I keep saying that useful estimation is possible is because I do it every single week. Hundreds of my peers in Pivotal and partner companies do it every single week. Hundreds of client developers do it every single week. But I hear that it's impossible. So I guess I'll change my résumé to read "Wizard".

by UK-AL 10y ago

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...
    - jacques_chester 10y ago
      Given that Pivotal wrote and then donated ownership of an entire containerised cloud platform, built from scratch, before any of Mesos, Kubernetes or Docker existed, I feel like we've done some fairly heavy original engineering. We estimate every story. Sometimes hilariously wrong (Diego was a classic example of a research-heavy project blasting past the initial gut-check estimates and improving in accuracy as it matured). But a lot of the time well enough to allow for useful business decisions to be made by ourselves and other members of the Cloud Foundry Foundation. The reason that I keep saying that useful estimation is possible is because I do it every single week. Hundreds of my peers in Pivotal and partner companies do it every single week. Hundreds of client developers do it every single week. But I hear that it's impossible. So I guess I'll change my résumé to read "Wizard".