5 ms·

I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business st

I feel like the core problem here is one that can never be resolved, because it's the result of two valid but opposing forces. On one hand you have business stakeholders, who can see the business reality - money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. On the other hand you have engineers, who either explicitly or implicitly understand the other truth - that reliably estimating a project requires knowing all the steps involved, and if you know all the steps involved, then you'd have already automated it.

dustingetz 3y ago
as you essentially say, software isn’t solved yet, so the business wins this one for now
klodolph 3y ago
When the problem can never be resolved, you redefine the problem until you find a version of the problem with a good solution. So if the problem is that software is hard to estimate, which is hard, we redefine the problem to something like “I want to be able to ship something people want to buy, before we run out of money” or “I want to ship a game in time for Christmas” or “I want to reduce operating costs so we don’t drown in debt.” Incidentally, the process of writing a software program is often the same process—redefining the problem until you find a problem with a good software solution, rather than finding a hard problem and throwing software at it until you die from exhaustion.
- danielvaughn 3y ago
  I love this.
- iopq 3y ago
  > “I want to be able to ship something people want to buy, before we run out of money” Buddy, if I knew the answer to the question "something people want to buy" I would be rich already
  - pixelrevision 3y ago
    Spoiler: no one thinks they should have to pay for software these days.
    - im_down_w_otp 3y ago
      I think a lot about the effect that ad-driven business models and open source must have had on the propensity to spend money on software products. Both in terms of pricing and in terms of build vs. buy. Mostly because I’m always musing about software developers’ hard earned reputation as the cheapest customer demographic on Earth.
      - TeMPOraL 3y ago
        I think about it too, sometimes. You know all the jokes/anecdotes about Microsoft and Bill Gates specifically calling Linux users and open source devs "communists" and accusing them of destroying the software industry? To the extent they actually said this, they were absolutely right - open source culture is very much responsible for destroying the viability of a simple and honest "pay money in exchange for value" business model in software. This of course didn't make software free - the market switched to monetizing it with worse, end-user-abusing models, like SaaS subscriptions and "free, but with ads". FWIW, I'm still enjoying, using and supplying open source, especially that as a power user, I can get a better deal on the whole thing. However, I think we need to recognize the unintended consequences this has, and that in a sense, we're ourselves responsible for the shitty and abusive industry we work in and live with.
  - roeles 3y ago
    Isn't that the whole reason why it makes sense to iterate, and release early and often?
pyrale 3y ago
> money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. That's a non-sequitur. there are plenty of ways to run a project under a budget that don't involve deadlines.
- danielvaughn 3y ago
  Interesting, though not sure I follow. My reasoning is that the ultimate deadline is the “we run out of money and go out of business” point, from which all other points follow. So a project may be organized differently, but under the hood it’s all the same - get more money before you lose all the money.
  - pyrale 3y ago
    Say you have a half-sized team in order for the remaining people to get twice as much time. People working on the project will, on average, be more familiar with the problem. That's not a frequent answer, since most companies are more time-sensitive than budget-sensitive. But that's a good illustration of how budget and timeline are separate things. That being said, my initial message wasn't about that, but about the idea that plenty of organizational methods abandon tight deadlines in favor of early feedback. That usually works better when power is decentralized, since the higher you report to, the less people have time to actually look at what you produce (and therefore, the more they rely on low-involvement management methods such as setting deadlines). On the other hand, the more decision power is decentralized to the people actually using the software, the more early feedback will make setting deadlines redundant.
  - regularfry 3y ago
    This is only a hard deadline if you have to wait until the end of the project before any money happens. This is the problem with the word "project" and, more generally, with formal project management: it attempts to divide the timeline into "Before Delivery" and "After Delivery" and often it doesn't care what the world looks like other than as a bag of deliverables. That's not the only way to do it, of course, but it's the mental trap you set for yourself by thinking about things as Projects with a capital P.
constantcrying 3y ago
The solution is communication and having, at best, management which knows engineering and the potential hazards of planning. If both sides agree that any estimation is a wild guess made with many assumptions, then you can go from there. Of course that means planning is difficult, but knowing that your plans need adaption is far superior to be in denial about it.
pif 3y ago
> business stakeholders, who can see the business reality but do not want to understand that technical debt does slow things down, and as such it must be paid back as soon as possible. > engineers, who [...] understand the other truth and are oblivious to the fact that giving correct estimates is not the point. Shipping sellable functionalities at the deadline is the point! If the functionalities were sellable enough, rich documentation and elegant code will come. If they weren't, nobody will have to bother.
bkirkby 3y ago
"money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function." Runways being real doesn't mean you need deadlines. Deadlines are useful to motivate the unmotivated. The better path to dealing with shrinking runways is early and continuous delivery of valuable software. This is facilitated by making sure the team is aligned and onboard with the solution (for motivation) then giving them the environment, support, and trust to get the job done. This is further enhanced by self-organized teams since the best architectures, requirements, and designs emerge from self-organizing teams. With that emergence, the team will deliver valuable and working software at regular intervals (measured by weeks or months at most, preferring the short timescale) and the stakeholders will determine when that valuable software is valuable enough for customers to pay for. This early and continuous delivery is the primary measure of progress. It also facilitates a welcoming of changes to the requirements at any stage (as the focus is delivering value, not getting a roadmap done). Roadmaps and deadlines will often get in the way of this system of efficiency in software delivery precisely because the estimation game gives team permission to use all the time negotiated in the estimation, which is already padded enough to ensure an "under promise and over delivery." All of this is taken straight from the agile manifesto (which is over twenty years old now): https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html

dustingetz 3y ago

as you essentially say, software isn’t solved yet, so the business wins this one for now

klodolph 3y ago

When the problem can never be resolved, you redefine the problem until you find a version of the problem with a good solution. So if the problem is that software is hard to estimate, which is hard, we redefine the problem to something like “I want to be able to ship something people want to buy, before we run out of money” or “I want to ship a game in time for Christmas” or “I want to reduce operating costs so we don’t drown in debt.” Incidentally, the process of writing a software program is often the same process—redefining the problem until you find a problem with a good software solution, rather than finding a hard problem and throwing software at it until you die from exhaustion.

danielvaughn 3y ago
I love this.
iopq 3y ago
> “I want to be able to ship something people want to buy, before we run out of money” Buddy, if I knew the answer to the question "something people want to buy" I would be rich already
- pixelrevision 3y ago
  Spoiler: no one thinks they should have to pay for software these days.
  - im_down_w_otp 3y ago
    I think a lot about the effect that ad-driven business models and open source must have had on the propensity to spend money on software products. Both in terms of pricing and in terms of build vs. buy. Mostly because I’m always musing about software developers’ hard earned reputation as the cheapest customer demographic on Earth.
    - TeMPOraL 3y ago
      I think about it too, sometimes. You know all the jokes/anecdotes about Microsoft and Bill Gates specifically calling Linux users and open source devs "communists" and accusing them of destroying the software industry? To the extent they actually said this, they were absolutely right - open source culture is very much responsible for destroying the viability of a simple and honest "pay money in exchange for value" business model in software. This of course didn't make software free - the market switched to monetizing it with worse, end-user-abusing models, like SaaS subscriptions and "free, but with ads". FWIW, I'm still enjoying, using and supplying open source, especially that as a power user, I can get a better deal on the whole thing. However, I think we need to recognize the unintended consequences this has, and that in a sense, we're ourselves responsible for the shitty and abusive industry we work in and live with.
- roeles 3y ago
  Isn't that the whole reason why it makes sense to iterate, and release early and often?

pyrale 3y ago

> money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function. That's a non-sequitur. there are plenty of ways to run a project under a budget that don't involve deadlines.

danielvaughn 3y ago
Interesting, though not sure I follow. My reasoning is that the ultimate deadline is the “we run out of money and go out of business” point, from which all other points follow. So a project may be organized differently, but under the hood it’s all the same - get more money before you lose all the money.
- pyrale 3y ago
  Say you have a half-sized team in order for the remaining people to get twice as much time. People working on the project will, on average, be more familiar with the problem. That's not a frequent answer, since most companies are more time-sensitive than budget-sensitive. But that's a good illustration of how budget and timeline are separate things. That being said, my initial message wasn't about that, but about the idea that plenty of organizational methods abandon tight deadlines in favor of early feedback. That usually works better when power is decentralized, since the higher you report to, the less people have time to actually look at what you produce (and therefore, the more they rely on low-involvement management methods such as setting deadlines). On the other hand, the more decision power is decentralized to the people actually using the software, the more early feedback will make setting deadlines redundant.
- regularfry 3y ago
  This is only a hard deadline if you have to wait until the end of the project before any money happens. This is the problem with the word "project" and, more generally, with formal project management: it attempts to divide the timeline into "Before Delivery" and "After Delivery" and often it doesn't care what the world looks like other than as a bag of deliverables. That's not the only way to do it, of course, but it's the mental trap you set for yourself by thinking about things as Projects with a capital P.

constantcrying 3y ago

The solution is communication and having, at best, management which knows engineering and the potential hazards of planning. If both sides agree that any estimation is a wild guess made with many assumptions, then you can go from there. Of course that means planning is difficult, but knowing that your plans need adaption is far superior to be in denial about it.

pif 3y ago

> business stakeholders, who can see the business reality but do not want to understand that technical debt does slow things down, and as such it must be paid back as soon as possible. > engineers, who [...] understand the other truth and are oblivious to the fact that giving correct estimates is not the point. Shipping sellable functionalities at the deadline is the point! If the functionalities were sellable enough, rich documentation and elegant code will come. If they weren't, nobody will have to bother.

bkirkby 3y ago

"money doesn't grow on trees and runways are very real and scary, so without deadlines companies fundamentally cannot function." Runways being real doesn't mean you need deadlines. Deadlines are useful to motivate the unmotivated. The better path to dealing with shrinking runways is early and continuous delivery of valuable software. This is facilitated by making sure the team is aligned and onboard with the solution (for motivation) then giving them the environment, support, and trust to get the job done. This is further enhanced by self-organized teams since the best architectures, requirements, and designs emerge from self-organizing teams. With that emergence, the team will deliver valuable and working software at regular intervals (measured by weeks or months at most, preferring the short timescale) and the stakeholders will determine when that valuable software is valuable enough for customers to pay for. This early and continuous delivery is the primary measure of progress. It also facilitates a welcoming of changes to the requirements at any stage (as the focus is delivering value, not getting a roadmap done). Roadmaps and deadlines will often get in the way of this system of efficiency in software delivery precisely because the estimation game gives team permission to use all the time negotiated in the estimation, which is already padded enough to ensure an "under promise and over delivery." All of this is taken straight from the agile manifesto (which is over twenty years old now): https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html