Hacker News Reader

Comment by everdev | Hacker News Reader

I've been developing for clients for 20+ years and 9 times out of 10 they do under estimate, but I think it has to do with lack of knowledge rather than anything malicious.

I found myself doing it when I get quotes for home repair or construction. My mind immediately goes to "I don't think it should take that long" even though I have no idea how to estimate those types of projects.

I wonder if it's because with something I'm not knowledgeable about I'm only estimating what I can see, but there are 5-10 tasks that have to happen in the background to make that thing I can see work properly. I just have no idea what those background tasks are to begin with or how many.

View on HN

Please don't excuse this, when management over promises and devs "under" deliver, then the axe never falls on management. The best work environments I've seen are where devs and management work together to supply estimates of a reasonable scale and where time is taken in project planning to chop up big goals into small tickets in a developer-meaningful manner.

Absolutely, it makes no sense for a manager to set timelines without conferring with devs.

Devs should set timelines, and business people should set "how much benefit will this bring". The combination of these two things yields priority.

I agree, and the biggest difficulty that ends up coming out of this fact is that things like paying down tech debt are hard to justify from a business perspective, this is a legitimately hard problem that everyone who ends up in project planning will have to deal with. When you hit it try and rely on talks by experts in the fields and external resources to enlighten the business side as to the value that paying down tech debt will give you.

Paying down technical debt should be exactly as easy/hard to justify, as paying down monetary debt. They behave the same and have the same effects over time; that's why debt is such a good analogy.

I disagree, technical debt is a much more liquid quantity that can be easily paid off in as little or great a chunk as you wish. If you as a company offered to let everyone pay off tech debt with 10% of their time, but force it to be 10% on a daily basis you'll likely end up accumulating more debt - paying off monetary debt a little at a time by diverting x% of revenue to it is a particularly good way to handle debt as a private company as it ensures there's plenty to reinvest and the cost the debt is imposing is well known.

So tech debt is harder to subdivide arbitrarily, I'll buy that. And it's harder to quantify in the first place, which seems to be one of the theses of this "dear client" letter.

Not only harder to quanitify. "Tech debt" is frequently used by devs as an excuse to make changes that they'd personally like to do, but which aren't necessarily improvements, e.g. rewriting from one language to another, or rewriting code they find hard to understand because there are no comments (instead of understanding the code and adding comments).

Tech debt is manageable if you start out with the right culture.

If you start out with an environment where devs feel rushed, you will run up tech debt very quickly, and it will be harder to get on the same page later when dev slows to a crawl

> I found myself doing it when I get quotes for home repair or construction.

My quite recent conversation with a contractor about estimating our home renovation project went more or less like this: "Demolition: 2 days, foundation: 3 days, ground zero: 3 days, exterior walls: 3 days, floors: 1 day, ceilings: 2 days, attic and chimneys: 2 days... so about five months in total". I felt right at home and want to hire them. The jump from how much time each tasks seems to require in pure work effort to how long it may realistically take given the unknowns, downtimes, logistics and various overhead seemed similar to the way I do estimates. An hour here, a day there, another four hours for that... yeah, I need two weeks for this task.

Reply on news.ycombinator.com