3 ms·

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 almo

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.
  - Scarblac 3y ago
    In my experience pinning down user requirements (and then getting feedback on your understanding of their needs, and iterating on that) is one of the most important parts of software development, not just in "web design". It's also the hardest part of "complex business logic", and the main subject of books like Domain Driven Development. And it's the hardest part to estimate. To make estimates you must first get the requirements clear, but that's a major part of what you were trying to estimate.
yladiz 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. I see your point, but I would argue that estimates are more valuable than just discussing the task because they give you a shared language to quickly define how complex you think a task is, and can also help avoid getting too into the weeds about specific implementation details when talking about the task in general. There are definitely problems that can arise from estimation, but if you're able to avoid them, it can be a useful tool for a high functioning team.
- fnordpiglet 3y ago
  I’d counter further than this sort of estimation naturally arises in any discussion of a problems solution. The challenge arises from the recording, accounting, and aggregation of estimations for any purpose other than the development of the solution - which is important for the purpose of allocation of talent and sequencing of immediate dependencies. The thing is the error bars in these estimates are large and positively skewed so you need to make your estimates about the smallest possible piece of work, and attach as little importance and dependency on their accuracy as possible. The problem comes when you string estimates together and compound the mistake by assuming a precise estimate is an accurate one. I generally refuse to give precise estimates for that reason.

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.
- Scarblac 3y ago
  In my experience pinning down user requirements (and then getting feedback on your understanding of their needs, and iterating on that) is one of the most important parts of software development, not just in "web design". It's also the hardest part of "complex business logic", and the main subject of books like Domain Driven Development. And it's the hardest part to estimate. To make estimates you must first get the requirements clear, but that's a major part of what you were trying to estimate.

yladiz 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. I see your point, but I would argue that estimates are more valuable than just discussing the task because they give you a shared language to quickly define how complex you think a task is, and can also help avoid getting too into the weeds about specific implementation details when talking about the task in general. There are definitely problems that can arise from estimation, but if you're able to avoid them, it can be a useful tool for a high functioning team.

fnordpiglet 3y ago
I’d counter further than this sort of estimation naturally arises in any discussion of a problems solution. The challenge arises from the recording, accounting, and aggregation of estimations for any purpose other than the development of the solution - which is important for the purpose of allocation of talent and sequencing of immediate dependencies. The thing is the error bars in these estimates are large and positively skewed so you need to make your estimates about the smallest possible piece of work, and attach as little importance and dependency on their accuracy as possible. The problem comes when you string estimates together and compound the mistake by assuming a precise estimate is an accurate one. I generally refuse to give precise estimates for that reason.