3 ms·

Exactly - I think all projects are budget constrained really. It's funny how even various "must haves" from the start of the project get cut, other things snea

by stuaxo 4y ago

Exactly - I think all projects are budget constrained really. It's funny how even various "must haves" from the start of the project get cut, other things sneak in. The back log grows and grows. On the other side: if we increase productivity by say 3x, will we cut the backlog or will it grow 3x faster ? I think we would, at least have a much better chance of exceeding our MVPs from the start of the project.

bcrosby95 4y ago
I generally agree. That said, I think anything that makes it to the backlog is naturally low value: if it were higher value, it would have been pushed up. The reality is programming is a form of automation. The world's thirst for automation is insatiable. I don't think programming will always exist, but think of it this way: when you eliminate them, you automate automation. We've never been in a scenario like that, and it would be quite the thing to behold. Think of it a bit like high frequency trading, but without the regulation or the barrier to entry. Sounds "great."
- Quarrelsome 4y ago
  > That said, I think anything that makes it to the backlog is naturally low value: if it were higher value, it would have been pushed up. This assumes the company is making sound decisions. I see companies prioritise new sales over features that would make the software more usable and effective in existing deployments. This prioritisation of immediate cash flow makes it much harder for the organisation to understand why some customers ditch the product later or don't use it enough to knit it into their processes. It is the perennial enterprise question as to whose needs are more important? The features the CEOs/CTOs of new customers ask for, or the productivity features the users of the products ask for. In other cases operational efficiency can be easily backlogged just because its harder to perceive. I've seen specialists and consultants be required for installation and setup because key features required for ease of deployment and use are never prioritised. Its easier budgetarily to just write a bit of python to paper over some cracks than get the required features into the core product but this just broadens the code base and arguably increases the liability. Later, managers might hand-wring about why its so expensive to deploy and maintain without ever being able to prioritise the relevant tickets to address those issues.

by stuaxo 4y ago

bcrosby95 4y ago

I generally agree. That said, I think anything that makes it to the backlog is naturally low value: if it were higher value, it would have been pushed up. The reality is programming is a form of automation. The world's thirst for automation is insatiable. I don't think programming will always exist, but think of it this way: when you eliminate them, you automate automation. We've never been in a scenario like that, and it would be quite the thing to behold. Think of it a bit like high frequency trading, but without the regulation or the barrier to entry. Sounds "great."

Quarrelsome 4y ago
> That said, I think anything that makes it to the backlog is naturally low value: if it were higher value, it would have been pushed up. This assumes the company is making sound decisions. I see companies prioritise new sales over features that would make the software more usable and effective in existing deployments. This prioritisation of immediate cash flow makes it much harder for the organisation to understand why some customers ditch the product later or don't use it enough to knit it into their processes. It is the perennial enterprise question as to whose needs are more important? The features the CEOs/CTOs of new customers ask for, or the productivity features the users of the products ask for. In other cases operational efficiency can be easily backlogged just because its harder to perceive. I've seen specialists and consultants be required for installation and setup because key features required for ease of deployment and use are never prioritised. Its easier budgetarily to just write a bit of python to paper over some cracks than get the required features into the core product but this just broadens the code base and arguably increases the liability. Later, managers might hand-wring about why its so expensive to deploy and maintain without ever being able to prioritise the relevant tickets to address those issues.