Hacker News Reader

Comment by rubidium | Hacker News Reader

I basically believe that building a house is a creative process that you are always doing for the first time.

As a general contractor you can’t expect me to provide a timeline of when it will done. This house has never been built this way before.

…

That way of speaking would fly in no other engineering discipline. Software, while it possesses some interesting differences from other fields (eg mechanical, electrical) has some massive growth to do in terms of actually developing engineering skills.

The biggest problems I see with sw engineers who complain about estimating work are (1) lack of experience (2) lack of rigor and (3) lack of effective teamwork.

A mature sw team with good disciple around getting user input and estimating work is totally possible. I’ve seen it.

This who think software is un-estimable compared to other engineering fields are just giving themselves an excuse from accountability.

View on HN

"This house has never been built this way before." That implies someone's already designed how it's going to be built?

What I often see in software that you're expected to give estimates on the spot before there's a design. You're expected to be the designer and implementor, and you're expected to say how long it'll take before you've started designing.

"I need features X, Y and Z" isn't a design.

And if you think other engineering disciplines are different, please go ask an EE how long it'll take -- or what it'll cost -- to make a board with a 2 GHz SoC and 8GB of LPDDR4 and PCIe. (That's not a design, and if you don't get laughed at, you'll learn that the answer depends massively on the design)

And just to add to all the other responses pointing out why this is a bad analogy, estimates on building a house assume fixed dependency costs. You need wood? You know where to get it, how quickly it will arrive, and what it will cost you. Software, you need some data? You have NO IDEA what the cost of getting it will be; who owns that system, how quick they are to respond, is there an API already in place, is the data in a format you can work with, etc. What was a "yeah, we've got an API you can use" "great, a day" turns out "Oh, that API isn't actually able to provide you data at the scale you want, and it also only allows querying by ID; if you want ALL the data we'll need to build a new API, and you'll need some sort of caching layer, and we need to discuss the ways we invalidate that cache to make sure it's sufficiently consistent for your needs and etc etc"

It's like what happened to the home building industry with the pandemic. Suddenly the cost of materials has shot up, the availability has dropped, and everything went up in the air. That's simply the default state in software, because every bit of software -is- unique. It would be like if every housing project was using unique materials. Literally a new material, that has to be fabricated, whose properties are unknown. Sure, it might be an alloy of something that previously existed, but it still brings in a bunch of unknowns.

The design of a house doesn't change every 3 weeks while it is getting built.

House construction is usually only started after a massive amount of detailed design and planning is done. This is priced in. This is almost never true for software.

Even with the above houses often take longer to build than expected and unforeseen issues can arise. Even the weather can screw things up.

The amount of unexpected issues that can come up in software is huge. Everything from a bug on a library that you use to differences in the exact machine that the software will run on vs where it was developed.

You say this like engineering is well known for accurate time estimates (especially for design). I haven't seen it. Even very big projects which are well understood overrun all the time in civil engineering, electronics engineering, aerospace engineering, the works.

I would say, firstly, the construction industry has a reputation for going over-budget and over-time. The difference is they are much less likely to have stuff that's not fit for purpose at the end of it (although there are exceptions).

The reasons for that?

There's thousands of years of experience in humankind of various types of construction and in-depth knowledge of the materials. Whereas in software we've only got 60-odd years of experience and the materials we use are generally untested.

On top of that, when they use new materials in construction, there is a legal and engineering requirement to test those materials before they are used generally. In software we just go "ooh, look new Javascript framework" and dive on straight away.

To add to the house analogy...

Someone is given a house building estimate of 6-8 months.

They they proceed to have business cards printed up, and start ordering materials to be shipped to their house for their new home business, and they slated everything for month 5. And they've already invited their family to come stay with them on month 6 day 2 to stay in the guest bedroom in the basement. ("Yes, I told you I needed a basement last week! Someone on your team was in the room and they didn't say no!").

The house building analogy is pretty far off in many many respects.

There are codes and inspections you have to comply with. You want to change X? That will mean new inspections and new codes to follow. There are essentially no codes to follow in software (I wish there were).

Regarding houses, an estimate is an estimate. Unfortunately for the builder, though, it is usually treated as a quote. IME the work is never completed on-time, but the estimate (rather than the time) is still the basis for the invoice.

It is different with software estimates; I've never given an estimate to a customer, it's always been to a PM or a salesman, who then imagines a quote to give to the customer.

In the early days, devs were "given away" by the salesman as part of the hardware deal. As a consequence, dev work was a cost-centre. I'm glad that stopped happening!

As far as I'm aware, the construction industry uses different formulas for calculating how long typical classes of work will take to accomplish. They can plug the square footage of some task into a spreadsheet and have a reasonable estimate for building time.

From what I understand, a construction "blue book" would give work rates for common tasks. How long it takes one man to dig a trench 10 yards long, or lay a 1000 bricks. From this you could calculate how long the entire job would take.

When I first encountered "Project Managers" in the 80's they were still trying to fit this model to software development.

i've heard business leaders express the suspicion that sw eng teams are trying to avoid accountability by claiming estimating is too hard.

and every time i've seen people try to correct for this it results in different layers of management adding arbitrary fudge factors to the time estimate which inflates the actual time that it takes to do something. these corrections build inefficiency into the beginning of the project and bake them in.

it's an answer to "how do we not be wrong about when things will be done?" over "how do we move faster?"

> i've heard business leaders express the suspicion that sw eng teams are trying to avoid accountability by claiming estimating is too hard.

If we say that we don't know how long its going to take or how much its going to cost - can you blame them?

Lots devs like me have a comms issue. We would love to deliver stunningly brilliant complete package on the first attempt and we come across as secretive. We need to made to think about delivering an MVP and building a product up incrementally. This way those nervious bosses and investors can see that something is happening. I think the question is often not "how long is it going to take?", but rather "will you ever deliver something I can sell?".

Reply on news.ycombinator.com