5 ms·

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting

What I see - and have seen since I started doing this 30+ years ago - is that the date is _always_ more important than the actual deliverable. Always. Meeting "the date" is the only thing that's tracked (but it also never happens). It's even justified through vague analogies like Joel Spolsky's admonition that "you wouldn't buy a pair of jeans without knowing how much they cost" without ever doing a slightly deeper dive into how developing software is different than selling a pair of jeans. All of the collaboration artifice that the author is referring to seems to me to always be a futile attempt to meet "the date". That software development might itself be _inherently_ unpredictable is never even considered, even though there are a lot of reasons to suggest that it is: by definition, the software you're developing has never been developed before, or else you could just use the thing that already exists. I had a glimmer of hope in the late 90's when the agile manifesto was published - everything about it seemed to me to read "software development activities can't be coordinated like a wedding banquet can, but you can at least make sure that everything is tracking toward a shared understanding". I guess I shouldn't have been surprised when "Agile" became "tell me exactly what you're going to do and how long each step will take" almost the instant of its inception.

whatever1 7mo ago
I love that LLMs are already copying humans when it comes to estimates. When asked for estimate they provide a very padded estimate of weeks. Then they proceed to implement the solution in 30”.
- youknownothing 7mo ago
  That's because LLMs don't actually think, they pattern-match. Since all the existing estimations out there are made assuming that a human is going to perform the task, the estimation that the LLM provides has the same inherent assumption. The LLM doesn't have a corpus of LLM-led estimations so it cannot take that into account.
parasubvert 7mo ago
IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.
- bombcar 7mo ago
  The corollary is that it's only the budget that is tracked that anyone cares about. Often your salary is not on that budget, so if it takes you twice as long but you don't have to buy/hire/use AWS, winner.
  - anon7725 7mo ago
    As someone who once spent two months reworking a system because a 4GB Oracle instance was okay, but 8GB was verboten, I agree.
  - strangattractor 7mo ago
    Salary does not need to be on the budget because it is the same whether you work 40hrs per week or 80.
- youknownothing 7mo ago
  To me, the _real_ thing that matters isn't quite date or budget, but something that somehow acts as an umbrella to both of them: the promise. When you promise to deliver something by a day, or within a budget, it's very clear whether you met your promise or didn't. However, when it comes to functionalities, there is more of a grey area: you can start to argue that something _mostly_ works, that some bugs are always inherent, or that this functionality actually is not really needed because the problem can be fixed in an operational way, or that the requirements have changed, or that it was just a nice-to-have... but money/time don't have this grey areas.
  - 7mo ago
MetaWhirledPeas 7mo ago
> the date is _always_ more important than the actual deliverable. Always. Hah! You just gave me an idea for a new methodology. Date-bound delivery. - The business tells you what they want, as they do - The business tells you when they want it, as they do - The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted. - As the date nears, more edge features get trimmed - As the date arrives, something is always ready to deliver, no matter how miniscule Such a methodology would ensure delivery, but not necessarily the contents of that delivery. Post mortems would no longer discuss why something took so long, and instead would focus on why features were cut. If, as you say, the date is always more important, wouldn't such a methodology be worth trying?
- parasubvert 7mo ago
  that's really what agile was supposed to be. at least in the places where I saw it was successful. every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design. every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.
  - MetaWhirledPeas 7mo ago
    Yes, but expanded to the full deadline instead of only the short iterations. The business does not care about week long deadlines. They need something on May 23 so they can achieve _______. My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on making it happen. In other words, usually it doesn't happen. But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.
    - 7mo ago
analog31 7mo ago
The natural extension to Spolsky’s quote is: Unless someone else is paying for the jeans. I think the smaller the organization, the more likely that a software projects has real stakeholders. In bigger, more mature organizations, the experienced players have arranged their affairs so that their career progress doesn’t depend on delivery of software: Late, early, or ever. For instance I work on the “hardware” side of technology development, and I tailor my annual performance review goals so that a deliverable is satisfied when I can demo it with code that I’ve written myself.

whatever1 7mo ago

I love that LLMs are already copying humans when it comes to estimates. When asked for estimate they provide a very padded estimate of weeks. Then they proceed to implement the solution in 30”.

youknownothing 7mo ago
That's because LLMs don't actually think, they pattern-match. Since all the existing estimations out there are made assuming that a human is going to perform the task, the estimation that the LLM provides has the same inherent assumption. The LLM doesn't have a corpus of LLM-led estimations so it cannot take that into account.

parasubvert 7mo ago

IMO (also 30 years in the biz), it's rarely the date, that's #2. it's the budget. They'll forgive you if you're slightly late, they'll hate you forever if you ask for more money. Agile works really well if you have a good product owner that has secured appropriate budget for the level of uncertainty in the endeavor & can make decisions and not be overridden by extrinsic forces. Everything else is negotiable.

bombcar 7mo ago
The corollary is that it's only the budget that is tracked that anyone cares about. Often your salary is not on that budget, so if it takes you twice as long but you don't have to buy/hire/use AWS, winner.
- anon7725 7mo ago
  As someone who once spent two months reworking a system because a 4GB Oracle instance was okay, but 8GB was verboten, I agree.
- strangattractor 7mo ago
  Salary does not need to be on the budget because it is the same whether you work 40hrs per week or 80.
youknownothing 7mo ago
To me, the _real_ thing that matters isn't quite date or budget, but something that somehow acts as an umbrella to both of them: the promise. When you promise to deliver something by a day, or within a budget, it's very clear whether you met your promise or didn't. However, when it comes to functionalities, there is more of a grey area: you can start to argue that something _mostly_ works, that some bugs are always inherent, or that this functionality actually is not really needed because the problem can be fixed in an operational way, or that the requirements have changed, or that it was just a nice-to-have... but money/time don't have this grey areas.
- 7mo ago

MetaWhirledPeas 7mo ago

> the date is _always_ more important than the actual deliverable. Always. Hah! You just gave me an idea for a new methodology. Date-bound delivery. - The business tells you what they want, as they do - The business tells you when they want it, as they do - The team does not say how long it will take. Instead, they say what they think they can deliver in the time allotted. - As the date nears, more edge features get trimmed - As the date arrives, something is always ready to deliver, no matter how miniscule Such a methodology would ensure delivery, but not necessarily the contents of that delivery. Post mortems would no longer discuss why something took so long, and instead would focus on why features were cut. If, as you say, the date is always more important, wouldn't such a methodology be worth trying?

parasubvert 7mo ago
that's really what agile was supposed to be. at least in the places where I saw it was successful. every week, something is delivered, and is demoable, with approved tests from the business. That thing represents the most important thing to the business relative to the risk prioritization from engineering & usability prioritization from design. every week, priorities can adjust, etc. and the cycle continues. hitting the actual 'release date' becomes much more knowable when you see the tangible date-driven progress on a regular cadence.
- MetaWhirledPeas 7mo ago
  Yes, but expanded to the full deadline instead of only the short iterations. The business does not care about week long deadlines. They need something on May 23 so they can achieve _______. My understanding of Scrum (not representative of all agile, I know) is that the velocity is supposed to be tracked and used for better predictions. In my experience this takes a very dedicated core of people who are intent on making it happen. In other words, usually it doesn't happen. But date-bound delivery is already our default mode of operation. We just don't like to admit it. We are going to deliver something on this date; we just don't know what, yet.
  - 7mo ago

analog31 7mo ago

The natural extension to Spolsky’s quote is: Unless someone else is paying for the jeans. I think the smaller the organization, the more likely that a software projects has real stakeholders. In bigger, more mature organizations, the experienced players have arranged their affairs so that their career progress doesn’t depend on delivery of software: Late, early, or ever. For instance I work on the “hardware” side of technology development, and I tailor my annual performance review goals so that a deliverable is satisfied when I can demo it with code that I’ve written myself.