Hacker News Reader

Comment by chii | Hacker News Reader

if you look at civil engineering at it's childhood stages that is, back when pre-historic man tried to build huts and lean-tos, you'd find that they too, didn't use any solid engineering practises, but simply tried different things and found out what worked. Being constrained physically makes it easier to determine what works, but the essense isn't any different to what software engineering is today.

I bet if we fast forward 1000 years, you'd find that software engineering will have become as rigorous as what we have today in civil engineering.

View on HN

This. Someday software developers will look back on us the way doctors look back on barbers' bloodletting.

Now that we brought out the doctor analogy, I have news for you....doctors deal with an unknown system, gain personal and institutional experience through trial and error, are basically detectives, are rarely working with full information, and have, despite their heroic efforts, a significant task failure rate (the patient dies).

How is that not like software engineering?

i dont think doctors fail as often as software projects. and they only fail on the fringes of medicine - like treating cancer, or rare diseases. You don't often see doctors failing to treat the cold or a broken angle badly that they kill their patients!

But in the software world, it seems the equivalent of the cold is a CRUD app, but still fails so often that it's newsworthily talked about when such a software project succeed!

No, that's not equivalent. A doctor treats a cold the same in every case. Software engineers are building different systems for each case, or else they would just use existing software.

Part of that is because software development is usually concerned with optimizing things for their sale value, not for being useful. In my example, a lot of problems could easily be solved with the same CRUD stack, if not for the needs concerning the design (i.e. it can't look similar to that competitor's thing) and other goals unrelated to actual use of the product.

A doctor doesn't really treat a cold though. They can treat an infection with anti biotics, they can treat something more specific than a cold with something. But if you come in with just a typical cold and say "treat me," they'll give you a placebo and prescribe lots of rest and water.

> I bet if we fast forward 1000 years, you'd find that software engineering will have become as rigorous as what we have today in civil engineering.

This isn't evident at all. In software, every situation is novel, so there is no room for repeatable processes.

You can build a "bridge library" once and tweak it for each situation, but you never need to develop a rigorous process to build that library again.

> every situation is novel

this is the point i m contesting - that most situations aren't as novel as the stakeholders think it is. The failure happens because the assumption that it's novel is there!

In general there may not be that much novelty per project, but that isn't the novelty that one needs to worry about in software projects. The relevant novelty is the novelty to the project team. Also lot of the novelty comes not from the technical side, but domain and organization that will be using the software.

This is a big argument in favor of experienced devs, who have deep technical and domain expertise.

Reply on news.ycombinator.com