Hacker News Reader

Comment by vasco | Hacker News Reader

Get your bathroom remodeled in your home and have the worker tell you it'll be done whenever and you'll understand why developers (or any hands on worker) is lacking in their skill and practice if they have no clue how long it takes them to perform their work.

"Management" or a PMs job will then be to aggregate those estimates so they can estimate at a higher level than you, similar to a project management in a construction site. But each person needs some semblance of an idea of when their part will be done.

The same way if you were remodeling your bathroom and your garden and want to tell your kids when the construction around the house will be done, you'll need the gardener's estimate and the plumber's estimate, plus maybe some buffer at the end, plus some time to go with the wife to get a new shower curtain, etc.

View on HN

If you tell your bathroom remodelers that you want green tiles after they have already done half of it with red and by the way you want the bathtub in a different place and you also aren’t sure yet if if you need a toilet bowl then their estimates will get out of hand pretty quickly. And your bathroom should be able to handle a 200 person family just in case although right now there are only two people in the house. And to save money you hire people from the street who don’t speak your language and have no experience but we all know one worker is one worker. They are all the same so when you hire cheap workers your cost is less without loss of productivity.

Why would you change plans and expect the construction crew's prior estimate to remain unchanged? Estimates change if the project changes. A commercial developer's job includes recognizing that and communicating changes upstream. Usually that leads to a negotiation, collectively determining how much to (try to) spend and which boondoggles are trutly important.

If a hired software developer told me up front, "I can't estimate because you will change things and then the old estimate will be wrong," all I can conclude is that this relationship is already dysfunctional.

> I can conclude is that this relationship is already dysfunctional.

Here's the thing, though: you wouldn't be wrong.

It may be different for contract development. For in-house development though, everywhere I've worked we've all always known that the relationship is dysfunctional. We also know that the dysfunction is everyone else's fault, not our own. So we just put up with it, because those assholes will never consent to fixing it, anyway, and just try to shift the blame to us instead.

Yeah I'm used to in-house, no material contract experience.

> the dysfunction is everyone else's fault, not our own

I specifically said the relationship. It takes two parties for effective communication to occur. An engineer who have given up trying because they assume experienced management will not listen, is just as bad as a manager that steamrolls their experienced engineers.

Yeah. What I'm getting at is that I think the relationship is doomed to dysfunction by a dysfunctional culture.

In most companies it works this way "Give me an estimate based on what I am telling you now. I haven't really thought it through and there are a lot of unknowns I view this estimate as a commitment that should be kept although I will probably make a lot of changes during development"

I think this is close. IMO, the problem is that we're talking about a group of concepts using vague language. Is it an estimate, a target, or a deadline? "Estimate" gets used in place for targets and deadlines all of the time and it sets up situations where expectations aren't properly managed.

This is the trick, everyone in the room knows it makes no sense. You change the requirements and then hold someone accountable for an estimate that is based off of different, often simpler requirements.

What you do is extract an extra amount of economic output out of your worker, who wouldn't say no to that? Then when it hits the wall, it's the dev's fault anyway. If it works out, you get a pat on the back!

If the dev says NO, the dev will still have to do the work and may even be coerced into doing so. Many junior developers think it's their fault, but they're being manipulated. That's why nobody likes seniors, too.

Of course. If management expects precise estimates then they need to provide precise requirements and be okay with adjusted timelines if they change the requirements. But that's fine. They can do that.

> then they need to provide precise requirements

> They can do that.

Yeah, no, they can't. Not at all.

While some, or a lot of that, is due to incompetence, it is also due to the nature of the beast: Software Development is an iterative process. You have to prototype and figure out what works and what not.

So regardless on how tight your processes are, whether you use agile or waterfall, it will never be possible to give perfect time estimates. You can only improve your risk-management.

No no no a bathroom isn't going to work anymore, we need a kitchen now.

"For competent people it should be pretty easy to convert the bathroom into a kitchen"

They best contractors I've worked with do just that, that is they don't give time estimates. They will say when they will start and how they will proceed but they never give estimates. They don't for the same reasons, they don't know. In their case it mostly revolves around sub-contractors and supply issues but the outcome is basically the same. There is to much noise to make an remotely accurate estimate so it is better to not do it.

I have a hard time imagining how such contractors would ever get a contract in the real world. I certainly wouldn't think of a contractor as highly skilled if they can't give an estimate.

Word of mouth. If someone you trust says they are good and get shit done then you hire them.

It's OK if you don't have money or time restrictions. Imagine that you have them.

Time yes, money no. They still give cost estimates.

We're doing applied mathematics, not bathroom remodeling. Try telling a mathematician to "story point" the conjectures they're working on.

Plumbers are doing applied physics, not rendering a button on a webpage. Try telling a physicist to provide an "estimate" for the cost of proving the big bang theory. Why should you expect an estimate for fixing your leaky bathroom faucet?

Half this site is crapping its pants over being replaced by AI being able to do their jobs with a prompt yet it thinks their work is sooo novel and unknowable.

If a computer scientist is doing completely routine tasks, they should be automating them, not estimating them every two weeks.

Most of software development is not computer science. Building a login page is a routine task.

Look man, even plumbing estimates are usually way off - but they know how long it takes to hook up two pipes that are 30' long for your new bathroom. They don't need to have meetings about it during the process. They don't need to talk to Home Depot about integrating with their broken API.

I work in an industrial physics and mathematics domain, and in that domain specifically, I must say it is very charitable to describe a majority of software engineers as doing "applied mathematics", if we are to interpret that as meaning "software engineers are participating in the practice of doing research mathematics." Except perhaps in some extremely reductionist view of what it means to "write a program" (e.g., programs are proofs, Curry-Howard, or some other idea), I don't think "applied mathematics" truly characterizes the work of, say, someone writing out a GitHub Action or adding a new RESTful endpoint to list a company's product catalog.

There's a pattern amongst software engineers in these and other discussions. When it comes to discussing management and resource estimation, some people describe software as the most arcane, idiosyncratic craft to exist. In other situations (e.g., where actual research mathematics or computer science is proposed to be used to solve a problem), software engineering has to be "simple", "aligned with best practices", and almost anti-intellectual.

The pattern of discussion (here and elsewhere), to me, indicates a survival instinct of sorts, if that makes sense. To this end, there's a sort of hypocrisy if it means being a software engineer is as unrestrained as possible: software is purported to be like applied mathematics in situations where it's advantageous to describe it as such (e.g., "we can't estimate because proving conjectures is intrinsically unpredictable") , then when the proposition is brought forth to engage with software as applied math (e.g., "team, we can bound the 99%ile perf by proving this recurrence on resource usage, and that'll give us evidence to modify our search algorithm with an adaptive radix tree."), software engineers push it away for something satisfactory to a CS101 student (e.g., "we can just implement auto-completion of our product catalog by searching a sorted array of item names, why complicate it?").

I understand the troubles of estimating resources for tasks and projects, and indeed the requests can sometimes be unrealistic and overbearing—I don't mean to suggest otherwise—but even the most technically sophisticated pieces of software are flush with "ordinary" kinds of programming tasks.

In my experience just working by priority works better than endlessly estimating tiny chunks of a project, that doesn't actually give any real predictability. Workplaces that go heavy on estimation and "agile" methodology produce bad software and not very reliably.

We're performing applied mathematics, but we're performing that task as engineers. The key is in 'applied'. Going from theory to practice takes planning and is not as unbounded as performing science in my opinion.

I think it's about balance, and a lot of software engineering projects would do better by steering more toward the academic research group model than the current fad of two week "sprint", plenty of non-technical pseudo-managers and endless micro-estimations.

What ever model works for a group of people producing software I'm fine with.

But as someone else said in this thread: If the question is more about who provides the estimate and less about why is there an estimate (also plenty of opinions about that in this thread) then I would say that time estimation is a integral part of an engineers job.

What makes someone an engineer is being able to provide a weighted solution towards the needs of a client or consumer. Not the best solution in the world, but the best solution for that client. If the requirements are that it should be delivered fast, you understand that the quality goes down. If the client wants high quality, it takes more time.

You're not seriously comparing research mathematics with software development, are you? You think you're expanding the breadth of human knowledge with your CSS tweaks of the shopping cart implementation? Give me a break.

> applied mathematics

Applied mathematics is a branch of mathematics. It's research. Someone studying solutions of the Navier-Stokes equations is doing applied mathematics. An accountant uses mathematics, but their work isn't "applied mathematics" any more than a plumber is an "applied physicist", or a veterinarian is an "applied biologist".

It's not less research mathematics than bathroom remodeling, that's for sure. I never tweaked any CSS, did you?

I’ve worked in construction. Estimates from contractors are notorious for being wrong. Almost every time.

But they are still expected to provide one, and to have some contractual requirements attached to said estimate.

So are software developers, especially ones doing contract work

Thanks for taking this avenue, the comparison to carpentry really annoyed me because all bathrooms or cabinets, or e-commerce/CRUD apps are the same right? (just because we're all tired of working on them doesn't mean our work is all copy and paste)

The most difficult part of any "hands on" job is time estimation - two people could give estimates of 3 days or 3 weeks on the same project and both be right.

I would assume the individual jobs could be fairly different, e.g. the plumbing doesn't come into the necessary places, shutoff valves not working.

Also, commissioner artists and authors are also asked for estimates. This is just basic professional courtesy when working with others.

When a contractor is remodeling your bathroom or your garden, the amount of time spent planning the design is insignificant compared to the cost of labor and supplies.

But in software, the planning is the entire project. The closer the plan is to covering every single possible case, the closer the software is to being done. In construction, the work doesn't even start until the plan is done.

Every one of these comparisons that involve a physical product whether it's contracting, bridge building, or manufacturing all completely miss the mark.

If you compare with other industries where the plan is the product, you'll start to see more similarities with software development. And the less the planning is cookie-cutter the more trouble those industries have with estimates as well.

Totally agree with you.

Looking at the comments only makes more obvious the snowflakeness and detachment from reality of the "software artists" bunch.

If they hire a guy to (re)model their bathroom, they expect it for free done yesterday. What I mean is that there's usually a complete turnover effect on the demands they have on people working on THEIR money and the lax and forgiving way they expect to be treated on OTHERS people money.

Well, much easier for a bathroom. It isn't like you have to have meetings, planning, interact with third parties, etc.. when redoing a bathroom!

If a client asks me for "an endpoint that accepts a text file and gives me a PDF" I can let them know how long it will take.

Most software projects can't be described like that!

What a funny analogy because these projects almost always run over the estimate.

Reply on news.ycombinator.com