Hacker News Reader

Comment by xyzzy123 | Hacker News Reader

The top down push for timelines is because:

In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects.

I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money.

Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.

View on HN

The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.

1. Think about what product/system you want built.

2. Think about how much you're willing to invest to get it (time and money).

3. Cap your time and money spend based on (2).

4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.

If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.

How would you decide between doing project (a) this quarter, or project (b)?

If you cannot (or refuse to) estimate cost or probability of success in a timebox you have no way to figure out ROI.

To rationally allocate money to something, someone has to do the estimate.

The exact same way you'd treat any other investment decision.

In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.

You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.

You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).

When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.

What you're asking is the equivalent of going to a company whose equity you've bought and asking them: what's the price going to be in 6 months' time?

Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.

How much plumbing knowledge do you have?

Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.

I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.

I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.

Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...

I bet if SWEs were seeing anywhere near that 1.5k per day they’d be more inclined to pay attention.

But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.

Reply on news.ycombinator.com