Hacker News Reader

Comment by slededit | Hacker News Reader

If you have multiple teams competing for features, it shouldn’t be too hard to sell it that way.

“If we could open up 780 days on the schedule - what new features would you like?” At this point you want the client dreaming of all the extras they never thought they’d get to have.

Then at the end you mention the 20 day delay. At this point they will feel the “loss” of the new features they just imagined. It’s an extremely powerful sales technique that works almost everywhere.

Given your earlier comments about the extra 20 days they seem particularly susceptible to this technique.

View on HN

If you announce that you have 4 man years free for new tasks, in a team that may not even have 4 developers, after abandoning a feature that already existed and worked, you're delusional and so is the stakeholder if he believes it.

I agree on the principles nonetheless. You want clients to write a formal request for new features, then development has a backlog of requests and can prioritize them.

Clients might not like the prioritization but that's life, limited bandwidth, it's simple to show there is too much to do and not enough resources.

I’m using the numbers I was given as I’m not in a place to judge if they are realistic. Certainly if you make false promises no amount of sales techniques will save you in the long run.

The 200000 vs 10000 (and therefore the 20 vs. 780 man days) come straight from your example. Which is part of the problem: while I know for sure that are a lot of things that should be refactored/changed/improved/cut off it would be very difficult for me to give an estimate of "how much resources we save over the next year" - as a simple example, I could revamp significantly the GUI (God knows how much it needs it)... and in the next six months I get 85% of the requests for changes having to do with business logic, financial batches running at the end of the month and stuff like that, maybe because there are new regulatory hurdles to clear like GDPR or The EU Travel Directive. Then the promised extra resources that would have become "available" fail to materialize, and the whole initiative is considered a failure. Good luck trying this again on the next year.

If you can’t quantify the benefits then how do you know if it’s worth doing?

Everyone else has to justify their programs with a cost/benefit analysis. I don’t think software should be immune.

The benefit depends on what part of the system I decide to optimize. If I guess right (and enhance something impacted by many/big requirements in the future) I will reap good results. If I enhance something which stays basically untouched for the rest of the FY I will be considered a fraud or misguided.

Applications developed internally don't necessarily have a roadmap (or might have it and abandon it 2 weeks into the new year because). Problem is, nobody will consider you a hero for sticking to the (now obsolete) plan.

Reply on news.ycombinator.com