Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Software the UFOlogy of Engineering Disciplines?

codemanship.wordpress.com

Post reply on HN
Print view View original

181–186 of 186 posts

Re: Is Software the UFOlogy of Engineering Disciplines?

#181

Post by guhidalg »

mwcampbell wrote: post #173
tptacek wrote: post #24

Earlier quoted context omitted.

Helps to have more of the quote: He said that programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'”. The “analysis-by-synthesis” view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant.

Shouldn't that make us want to fight to simplify our software stacks to the point where we can do analysis by synthesis, building from simple, well-understood parts, again?

You can certainly do that if you restrict software to be a mathematical artifact instead of an executable running on one of 3 kernels with different APIs and behaviors, let alone the mountain of dependencies your code will build and link against.

The reality is that the machines we write software for are complex, and trying to abstract it away and simplify it will introduce more abstractions that someone has to understand and deal with when they inevitably leak. It's not all bad, all this shit we're writing makes a lot of money.

Re: Is Software the UFOlogy of Engineering Disciplines?

#182

Post by marcosdumay »

wavemode wrote: post #169
marcosdumay wrote: post #152

Earlier quoted context omitted.

> Rather, it is that systems are tested thoroughly enough, and designed with enough failsafes and redundancy Yeah... That's one of the main reasons why engineers from most other disciplines have a lot of difficulty creating large reliable software. Testing systems and adding failsafes are not nearly enough for system reliability, and not the best way to add it to software. It's almost enough for mechanical engineerin…

> Testing systems and adding failsafes are not nearly enough for system reliability, and not the best way to add it to software. Then what is the best way?

Just like with systems reliability, nobody knows it well. But some things we do know are that keeping it simple quickly becomes more impactful than adding failsafes, and you need to design quality holistically from the top down, and not focus at failures or known failure modes.

And just to say, the fact that nobody has any idea how to engineer systems reliability is the main reason why we have a duopoly in large airplanes that everybody expects to turn into a monopoly soon. If we knew how to do it, companies would pop into the market all the time.

Re: Is Software the UFOlogy of Engineering Disciplines?

#183

Post by Normal_gaussian »

sampo wrote: post #172
Normal_gaussian wrote: post #170

Earlier quoted context omitted.

The largest obstacle to this theory being taken seriously is the lack of evidence in long term records, such as ice cores. Our current age will show up in future ice cores as a massive spike; we affect CO2, Methane, Sulfates, and probably a lot more. Additionally we produce and have produced various synthetic compounds that will remain detectable in the environment for hundreds of thousands of years, if not millions.…

> This is highly unlikely Absolutely. But are visitors from other star systems any less unlikely?

Sorry, I was overly polite. It should have read "this is a bloody stupid position to take".

Visitors from other star systems are significantly more likely (on the order of dice roll vs impossible) than a secret highly advanced human society developing and remaining present and hidden.

Re: Is Software the UFOlogy of Engineering Disciplines?

#184

Post by sarchertech »

jiriro wrote: post #179
sarchertech wrote: post #162

Earlier quoted context omitted.

“Quality” is subjective, so you’re correct that it’s not about quality. A tool designed with a planned lifespan of 100 hour lifespan is just as much a product of engineering as one designed to last 10k. Responsibility though is very much is a central component of capital E Engineering. The modern profession in many ways is a direct response to big newsworthy engineering disasters.

Responsibility does not have anything to do with engineering capital E or whatever. If you pay me I can of course sell you some responsibility or whatever. This is called business.

When you hire a Professional Engineer there are minimum safety standards that they must meet. They can't charge you less and waive their liability. They are essentially required by law to "sell you some responsibility".

Re: Is Software the UFOlogy of Engineering Disciplines?

#185

Post by HeyLaughingBoy »

jayd16 wrote: post #176
HeyLaughingBoy wrote: post #146

Earlier quoted context omitted.

> What is the software equivalent of spacing studs interspersed with fireblocks that we're not doing? You're comparing apples to hockey pucks. For the analogy to hold, you need to specify what industry the software is for. i.e., if I'm building a garden shed, I don't need a specific stud spacing or even fireblocks at all. Hell, I can build it from raw timber if I have enough of it.

That doesn't really sound like an invalid analogy, you just don't need the same fire code for all structures but there are still fire codes that apply to building sheds. I'm not sure what your point is. Like, ok, you came up with a structure that doesn't need a lot of structural engineering but clearly others do. So what are you trying to say?

That asking about a "software equivalent" isn't possible to answer without specifying an industry or what's being built. It will vary considerably between an human-implantable device or a game on your phone.

Re: Is Software the UFOlogy of Engineering Disciplines?

#186

Post by skeezyjefferson »

layer8 wrote: post #57
skeezyjefferson wrote: post #42

Earlier quoted context omitted.

this covers only the most technical fields that already specify things rigorously. most people arent technical enough to even understand what a formal spec is, so how do you deal with them? insist they learn formal methods?

Most people aren’t software engineers, so it’s not clear why that should be a problem.

...? because you have to deal with them? as in theyre paying you to write software. so now what? the idea falls apart when it meets reality
Post reply on HN