3 ms·

> Software estimation is basically a useless craft. It depends on how you're thinking about estimates. Just saying they're useless is arguably missing the bene

by yladiz 3y ago

> Software estimation is basically a useless craft. It depends on how you're thinking about estimates. Just saying they're useless is arguably missing the benefit of the process. Estimates are not generally useful in and of themselves (as in, the estimate value isn't particularly useful), but the process around agreeing on the value within a team is. If you're on a team and estimating a task during refinement, and there are wildly different estimates from the different team members, then the definition and/or understanding of the task is wrong and it needs more clarity and discussion. Another thing is that date estimates are problematic, and estimates should more generally be used to estimate complexity, and while they might be linked in some way, they're not the same. The issue with estimates, in my opinion, comes down to the process after the value has been determined. If it's used as a benchmark or metric in some way, then you get into problematic situations. I also do disagree with this: > The reality is, unlike building a building, often the software being built has a ton of unknowable elements that are due to the software being bespoke in many crucial ways. Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task.

CodeMage 3y ago
> Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. Funny, I've been hearing this constantly over the 24 years of my professional experience as a software developer and I've yet to see it proven true. Unless we're talking about toy examples like Hello World, developing quality software is devilishly complicated and, in my opinion, downplaying this complexity as an "excuse" is in itself an excuse to compromise quality. EDIT: Fixed a few words my phone auto-"corrected" for me.
fnordpiglet 3y ago
I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion. Estimation is almost exclusively for the benefit of management is determining when something will be done. I would say if this is true in your work: > Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. You’re probably working on fairly rote easily producible stuff. That’s not a knock for sure - buildings are complex projects but are easily producible and rote, and contain some but not many unknowns. I imagine in modern times (I’ve not tried to do it for about 25 years tho, and it definitely was complex then!) making modern websites and e-commerce stuff is fairly rote and predictable and mostly a design process. Developing something innovative is full of unknowns that can only be determined by trying to do it. Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. Developing complex business systems as well.
- epups 3y ago
  > Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. I think we can all agree that the vast majority of software work does not belong to the categories above, and is therefore relatively predictable.
  - fnordpiglet 3y ago
    I don’t think I agree, I think most software is written in the context of megacorps, and it’s mostly complex business logic. Further, an awful lot of developers work in government, military, scientific, big tech, and a bunch of very technical software development endeavors. I think some work that can nominally be called software, which I classified as mostly graphic design and related plumbing in my response is relatively predictable. My web design folks claim they’re very productive in scrum, mostly because it’s mostly about pinning down customer requirements and churning out known patterns. This is not something you get a degree in computer science to do, and I don’t really consider it software development. Likewise, setting up SAP integrations or Salesforce integrations isn’t really software development. It’s something like it - but there’s no development of software - just configuration of already written software to customize it to a context. I’m sure we can disagree here, but I would note we don’t all agree.
    - epups 3y ago
      Sorry but your entire point sounds like a no true scotsman to me. The work of developing useful software which most people get paid to do is, in fact, relatively predictable. Maybe we are all truly peasants who do inferior work that you don't dare classify as software, maybe what you do is truly groundbreaking (I already accepted that as a valid exception), or maybe you have been working with people who just suck at estimates.
      - fnordpiglet 3y ago
        I’m not saying design based work isn’t real work or has no value. But I don’t consider it software development in the way I don’t consider magazine layout software development, even though it’s complex and difficult work. But it’s fairly rote and mechanical, and doesn’t require any software development. For instance I consider developing react to be software development. I consider making a chat system in react software development. I do not consider making a brand layout using a web framework to be software development. As an example, generally in business you classify software development as R&D for accounting purposes. It’s speculative, has uncertain payout, uncertain development times. Website creation on the other hand can’t be treated as R&D. It’s capitalized under a different amortization schedule. I’m sorry if it sounds like I’m making some qualitative distinction in terms of value or whatever. That isn’t my point. My point is when we discuss software development and software engineering they are about development of software. I think most people can distinguish between front end web development, and say, developing a web development framework as distinctly different pursuits with very different characters in terms of skill sets, riskiness, predictability. You can adopt an expansive view, but you took issue with my statement without taking into consideration my measure.

by yladiz 3y ago

CodeMage 3y ago

> Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. Funny, I've been hearing this constantly over the 24 years of my professional experience as a software developer and I've yet to see it proven true. Unless we're talking about toy examples like Hello World, developing quality software is devilishly complicated and, in my opinion, downplaying this complexity as an "excuse" is in itself an excuse to compromise quality. EDIT: Fixed a few words my phone auto-"corrected" for me.

fnordpiglet 3y ago

I’d say just discussing how a task will be implemented susses out whether it’s understood. Estimation isn’t a useful part of that discussion. Estimation is almost exclusively for the benefit of management is determining when something will be done. I would say if this is true in your work: > Honestly, software development is not as complex as people like to believe and there aren't as many unknowable elements as people like to think, and in my opinion this line of thinking is just an excuse to not actually think about what needs to be done to complete a task. You’re probably working on fairly rote easily producible stuff. That’s not a knock for sure - buildings are complex projects but are easily producible and rote, and contain some but not many unknowns. I imagine in modern times (I’ve not tried to do it for about 25 years tho, and it definitely was complex then!) making modern websites and e-commerce stuff is fairly rote and predictable and mostly a design process. Developing something innovative is full of unknowns that can only be determined by trying to do it. Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. Developing complex business systems as well.

epups 3y ago
> Building arbitrary scale SaaS data services, complex cryptographic platforms, more recently AI stuff, all are replete with unknowns. I think we can all agree that the vast majority of software work does not belong to the categories above, and is therefore relatively predictable.
- fnordpiglet 3y ago
  I don’t think I agree, I think most software is written in the context of megacorps, and it’s mostly complex business logic. Further, an awful lot of developers work in government, military, scientific, big tech, and a bunch of very technical software development endeavors. I think some work that can nominally be called software, which I classified as mostly graphic design and related plumbing in my response is relatively predictable. My web design folks claim they’re very productive in scrum, mostly because it’s mostly about pinning down customer requirements and churning out known patterns. This is not something you get a degree in computer science to do, and I don’t really consider it software development. Likewise, setting up SAP integrations or Salesforce integrations isn’t really software development. It’s something like it - but there’s no development of software - just configuration of already written software to customize it to a context. I’m sure we can disagree here, but I would note we don’t all agree.
  - epups 3y ago
    Sorry but your entire point sounds like a no true scotsman to me. The work of developing useful software which most people get paid to do is, in fact, relatively predictable. Maybe we are all truly peasants who do inferior work that you don't dare classify as software, maybe what you do is truly groundbreaking (I already accepted that as a valid exception), or maybe you have been working with people who just suck at estimates.
    - fnordpiglet 3y ago
      I’m not saying design based work isn’t real work or has no value. But I don’t consider it software development in the way I don’t consider magazine layout software development, even though it’s complex and difficult work. But it’s fairly rote and mechanical, and doesn’t require any software development. For instance I consider developing react to be software development. I consider making a chat system in react software development. I do not consider making a brand layout using a web framework to be software development. As an example, generally in business you classify software development as R&D for accounting purposes. It’s speculative, has uncertain payout, uncertain development times. Website creation on the other hand can’t be treated as R&D. It’s capitalized under a different amortization schedule. I’m sorry if it sounds like I’m making some qualitative distinction in terms of value or whatever. That isn’t my point. My point is when we discuss software development and software engineering they are about development of software. I think most people can distinguish between front end web development, and say, developing a web development framework as distinctly different pursuits with very different characters in terms of skill sets, riskiness, predictability. You can adopt an expansive view, but you took issue with my statement without taking into consideration my measure.