3 ms·

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

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.
- evilantnie 7mo ago
  I feel like everyone in this reply chain is looking at this from a different angle of Fast, Good, Cheap. Pick two.
  - tharkun__ 7mo ago
    That was literally the first thing I thought reading from OP comment down to your parent. Then I thought: Sure but management made the devs promise these things. We don't do it of our own volition (exceptions prove the rule - some people are conditioned to do it of course).
  - elliotec 7mo ago
    Exactly. The old Iron Triangle. One of the three will always be most important depending on the constraints. Two of them will be possible.
ryandrake 7mo ago
That might be true in certain kinds of companies. I never worked in consulting, and I've always been so far down the totem pole that nobody has ever expected me to adhere to a monetary budget. I suppose I am extremely lucky, but at all places I've worked, I had no idea how much our software cost to build or how much revenue it brought in. If we needed a software license or development systems, or a specialized piece of hardware, we just requested it and it materialized. Often I didn't even know the per-customer unit price of the software. The only constraint that ever made it down through the huge tree of managers was the due date. Someone five managers above me was probably sweating the budget but to us low level developers, budget was never even a concept.
- parasubvert 7mo ago
  It varies on company culture and business model. Your situation sounds like R&D shops and how they often manage things. R&D usually is budget constrained at the company or division level (% of revenue) and you can only ask for it once a year. Next year's budget time determines if you get more or less. Time constraints come indirectly (proof of progress for budget expansion or more importantly declining revenue from existing products), But the only way management knows how to hold R&D accountable to ship is with dates as a forcing function, and those dates are often invented or organized around industry events (conferences, press events, etc). There are other ways to manage progress, dates are the most common lever. That can work but can be abused by bad management. I've usually preferred shops that say "it ships when it's ready", but they require special circumstances to maintain funding and measure progress. In general if what you build is more important than when it ships, "it ships when it's ready" is better than hitting a date with a dud. So long as there's value for the budget and a way to measure it.
  - doctorpangloss 7mo ago
    Hacker News discusses "deadlines" as one of many management strategies. How much depth is there really? Other industries use bonuses as a simple management strategy. The kinds of people writing blog posts like this do terribly boring work, which is the real problem.
codebje 7mo ago
As far as software development goes, money is almost perfectly correlated with time.
- parasubvert 7mo ago
  That's never been true. At minimum, as it's missing the most important variable: quantity of people. 1 person working for a year vs. 12 people working for a month could cost the same and have dramatically different results. And it ignores so many other aspects of effective use of productive capital in software dev (toolchains, cloud, AI, etc.)
  - codebje 7mo ago
    You are right, I didn't think that through properly!
atoav 7mo ago
I program for 20 years now and I think that what many people do wrong about these estimates is that they give them too early. The truth is that for many project the only truthful answer you could give someone on the question hoe long it takes is: "That depends on many things some of which I don't know, some of which we both don't know and some of which potentially nobody knows." After that you should say: "In my experience it takes betwern x and y weeks, with a lot also depending on how responsive your side is." Time estimates are always hard, not only in programming. And outside of programming one of the main insecurities is customers changing the plan or wanting adjustments. This is the side you can't really control, so it is best to get a feeling for the customer, their communication patterns and their expectations early on and factor it in. The other insecurity is tough problems you encounter during the programming phase. How well you can deal with those depends a lot on how experienced your programmers are and how much they were involved in the inital process. The truth is that the latter insecurities make up a main part of the whole thing and it has to be okay to tell a customer you can't give them an estimate before you know some more details.

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.

evilantnie 7mo ago
I feel like everyone in this reply chain is looking at this from a different angle of Fast, Good, Cheap. Pick two.
- tharkun__ 7mo ago
  That was literally the first thing I thought reading from OP comment down to your parent. Then I thought: Sure but management made the devs promise these things. We don't do it of our own volition (exceptions prove the rule - some people are conditioned to do it of course).
- elliotec 7mo ago
  Exactly. The old Iron Triangle. One of the three will always be most important depending on the constraints. Two of them will be possible.

ryandrake 7mo ago

That might be true in certain kinds of companies. I never worked in consulting, and I've always been so far down the totem pole that nobody has ever expected me to adhere to a monetary budget. I suppose I am extremely lucky, but at all places I've worked, I had no idea how much our software cost to build or how much revenue it brought in. If we needed a software license or development systems, or a specialized piece of hardware, we just requested it and it materialized. Often I didn't even know the per-customer unit price of the software. The only constraint that ever made it down through the huge tree of managers was the due date. Someone five managers above me was probably sweating the budget but to us low level developers, budget was never even a concept.

parasubvert 7mo ago
It varies on company culture and business model. Your situation sounds like R&D shops and how they often manage things. R&D usually is budget constrained at the company or division level (% of revenue) and you can only ask for it once a year. Next year's budget time determines if you get more or less. Time constraints come indirectly (proof of progress for budget expansion or more importantly declining revenue from existing products), But the only way management knows how to hold R&D accountable to ship is with dates as a forcing function, and those dates are often invented or organized around industry events (conferences, press events, etc). There are other ways to manage progress, dates are the most common lever. That can work but can be abused by bad management. I've usually preferred shops that say "it ships when it's ready", but they require special circumstances to maintain funding and measure progress. In general if what you build is more important than when it ships, "it ships when it's ready" is better than hitting a date with a dud. So long as there's value for the budget and a way to measure it.
- doctorpangloss 7mo ago
  Hacker News discusses "deadlines" as one of many management strategies. How much depth is there really? Other industries use bonuses as a simple management strategy. The kinds of people writing blog posts like this do terribly boring work, which is the real problem.

codebje 7mo ago

As far as software development goes, money is almost perfectly correlated with time.

parasubvert 7mo ago
That's never been true. At minimum, as it's missing the most important variable: quantity of people. 1 person working for a year vs. 12 people working for a month could cost the same and have dramatically different results. And it ignores so many other aspects of effective use of productive capital in software dev (toolchains, cloud, AI, etc.)
- codebje 7mo ago
  You are right, I didn't think that through properly!

atoav 7mo ago

I program for 20 years now and I think that what many people do wrong about these estimates is that they give them too early. The truth is that for many project the only truthful answer you could give someone on the question hoe long it takes is: "That depends on many things some of which I don't know, some of which we both don't know and some of which potentially nobody knows." After that you should say: "In my experience it takes betwern x and y weeks, with a lot also depending on how responsive your side is." Time estimates are always hard, not only in programming. And outside of programming one of the main insecurities is customers changing the plan or wanting adjustments. This is the side you can't really control, so it is best to get a feeling for the customer, their communication patterns and their expectations early on and factor it in. The other insecurity is tough problems you encounter during the programming phase. How well you can deal with those depends a lot on how experienced your programmers are and how much they were involved in the inital process. The truth is that the latter insecurities make up a main part of the whole thing and it has to be okay to tell a customer you can't give them an estimate before you know some more details.