Live data from Hacker News

Why writing software is not like engineering (2008)

cs.usfca.edu

41–50 of 62 posts

Re: Why writing software is not like engineering (2008)

#41

I consider software development an engineering discipline. In my weird, crazy world, engineering is all about discipline (sound of a riding crop slapping a leather-clad thigh), and follow-through . It's a lot less about slide rules and differential equations. I believe that the Romans that built aqueducts (often using coerced labor -otherwise known as "slaves") were engineers. They had a lousy numbering system, no co…

You can't be both a craft and engineering. I think the issue is misunderstanding what it means for something to be engineered. There is a correct answer. (Especially because you can always optimize for cost or a different quality metric)

I see things differently.

I believe that they can both coexist. I think that the prior art is centuries old.

Re: Why writing software is not like engineering (2008)

#42

I consider software development an engineering discipline. In my weird, crazy world, engineering is all about discipline (sound of a riding crop slapping a leather-clad thigh), and follow-through . It's a lot less about slide rules and differential equations. I believe that the Romans that built aqueducts (often using coerced labor -otherwise known as "slaves") were engineers. They had a lousy numbering system, no co…

You can't be both a craft and engineering. I think the issue is misunderstanding what it means for something to be engineered. There is a correct answer. (Especially because you can always optimize for cost or a different quality metric)

You are so wrong. Software is both a craft and engineering. All software fits your definition of cost and quality optimization. It is a craft in that a software engineer isn’t taught how to write the software you want, they’ve built a toolbox from crafting different types of solutions because their existing tools didn’t fit.

Re: Why writing software is not like engineering (2008)

#43
post #12

Earlier quoted context omitted.

It happens with slow technologies that ought to have standards as well. I do work with OS2.eu (Danish public sector owned open source software organisation) and we recently brought the first project into multiple supplier territory. It’s a Drupal PHP project, and as I understand that means that everything that gets build should follow Drupal standards that are pretty much set in stone. After 6 months of governance go…

Drupal and PHP is the standard chose? How? Were alternatives explored? This seems very odd as the choice for standardized websites. A better solution would be standardize a backend apis and setup standards around how data is queried and stored. Next standardize how that data is presented to the user and how the user can manipulate that data. None of this requires a specific technology and sounds like decisions were m…

You make a strong case for software not being engineering. Who should the client trust when every expert has something to sell, is not bound by an ethical code, and has experience that is incommensurable with every other expert's experience? Who are you to the client but another expert with a different solution to sell?

Re: Why writing software is not like engineering (2008)

#44

I switched from engineering to programming because of pay, but I can tell you the word Software Engineering is not exactly real unless you are doing some safety critical C or assembly. Whenever you have abstraction, you have lost what it means to be an engineer. There is really only 1 way to engineer something as you end up optimizing for various quality metrics, most often cost. There's only 1 correct answer for a b…

> Whenever you have abstraction, you have lost what it means to be an engineer.

That's an interesting observation. I'd say engineering does have abstractions, but they're much better. For example, treating an RSJ as a simple uniform piece of material is an abstraction. In reality it is a crazily complex mesh of crystals. But the abstraction is simple and well studied, so it can be used reliably.

Programming abstractions are less reliable. Even commonly used ones like "the filesystem" and "the heap" are vastly more complex. It is almost impossible to remember all the possible hazards when you use them.

Re: Why writing software is not like engineering (2008)

#45
post #35

Part of the problem is that software project decision makers view software projects as far more mutable than physical engineering projects. In a billion dollar construction project, everyone understands that if you want to change the design or significantly expand the scope halfway through, you're going to have a heck of a lot of increased costs & time. In software, it's very common to add scope or major design chang…

They do understand, they just want to not-pay. If construction companies figured out they could outsource labor to countries with far lower currency values and thereby not-pay for extra labor, they'd do the same.... oh wait...

They do understand

Not in my experience, which may not generalize. Your experience and my experience together won't really give a complete picture.

What I experience is this: Even on small projects I've had people say, "okay, can you just add this one thing in the next day or two?" And they don't understand until I walk them through in detail how that one thing is nearly as complex as the initial project, so they have to choose how important it is, and if it's important do they want to wait to release the whole thing or do a release in stages.

Of course my experience is not necessarily going to represent the whole.

Also when outside consulting groups are involved, I often see predatory behavior: they often agree to do any change asked for and don't bother to explain the costs and time involved until a deadline is missed and the budget is running out. At which point they say "the changes you requested have pushed us over the deadline and the extra time is going to cost $X".

Re: Why writing software is not like engineering (2008)

#46

Earlier quoted context omitted.

Drupal and PHP is the standard chose? How? Were alternatives explored? This seems very odd as the choice for standardized websites. A better solution would be standardize a backend apis and setup standards around how data is queried and stored. Next standardize how that data is presented to the user and how the user can manipulate that data. None of this requires a specific technology and sounds like decisions were m…

You make a strong case for software not being engineering. Who should the client trust when every expert has something to sell, is not bound by an ethical code, and has experience that is incommensurable with every other expert's experience? Who are you to the client but another expert with a different solution to sell?

I mean, I just gave the solution for software being engineering. Standards need experts to make decisions. Government shouldn’t reach out to an existing firm that’s locked into a specific technology.

The experts need to continue to audit, refine, and integrate on the standards. Locking in a specific technology is shortsighted and will cost a lot later.

Re: Why writing software is not like engineering (2008)

#47
post #5

Most engineering projects have standards. Not the cutting edge stuff, but most of it does. Many are from regulations and safety laws setting specifications for this and that, but some are simply there because they won by being the most popular. Software Development by contrast has no standards. You can hire two different enterprise sized companies with this and that certification in the exact same technologies, who c…

> If computer science wants to be engineering, I need to be capable of hiring an architect who makes plans that can be implemented by any supplier

You don’t though. This is just an artefact of the structure of your industry, being limited as it is by physical, geographic, and capital constraints. Software has none of those (capital used to be an issue but is no longer - this is perhaps why things are more flexible than 30yrs ago as you note).

You think you need these things because you see your role as an integrator - but software engineers already perform that function at a different level, via libraries and protocols.

Re: Why writing software is not like engineering (2008)

#48

I consider software development an engineering discipline. In my weird, crazy world, engineering is all about discipline (sound of a riding crop slapping a leather-clad thigh), and follow-through . It's a lot less about slide rules and differential equations. I believe that the Romans that built aqueducts (often using coerced labor -otherwise known as "slaves") were engineers. They had a lousy numbering system, no co…

You can't be both a craft and engineering. I think the issue is misunderstanding what it means for something to be engineered. There is a correct answer. (Especially because you can always optimize for cost or a different quality metric)

Many mechanical and electrical engineers see their work as craft.

Re: Why writing software is not like engineering (2008)

#49
post #12

Earlier quoted context omitted.

Standards can only happen when an industry has matured and moves slow enough for these standards not to be obsolete by next year. We have plenty of laws and standards regarding handling private information, payment systems, independent pen testing and so on. So it's incorrect to say we have "no standards" at all. Where it matters, we do. But to try and standardize a process that's evolving faster than a standard can…

It happens with slow technologies that ought to have standards as well. I do work with OS2.eu (Danish public sector owned open source software organisation) and we recently brought the first project into multiple supplier territory. It’s a Drupal PHP project, and as I understand that means that everything that gets build should follow Drupal standards that are pretty much set in stone. After 6 months of governance go…

It's silly to standardise on a technology. Standardise on the output definitions: accessibility, performance, ergonomics, compatibility.

In construction a standard isn't "use this make of hammer". It's "achieve this effect".

Re: Why writing software is not like engineering (2008)

#50

> The Economist magazine (Nov 27, 2004 p. 71) cites the Standish Group's estimates that "...30% of all software projects are canceled, nearly half come in over budget, 60% are considered failures by the organizations that initiated them, and 9 out of 10 come in late." In 2021 (as well as in 2004) it is meaningless to talk about "all software projects" without specifying domain, size, scope and project etymology. "Sof…

> nearly half come in over budget

That's much better than I would've thought.

Post reply on HN