Things I Believe About Software Engineering • Hacker News Board

Re: Things I Believe About Software Engineering

#41

Post by onion2k » Mon, Feb 03, 2020, 10:57 AM UTC

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

most worked correctly, for a very specific definition of correctly.

That doesn't mean incorrectness isn't there. That means the circumstances necessary for any incorrectness to manifest in a measurable way didn't happen.

Re: Things I Believe About Software Engineering

#42

Post by PopeDotNinja » Mon, Feb 03, 2020, 10:59 AM UTC

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

Software that doesn't have changing requirements is eventually trivial. You can logic your way to a reasonable solution eventually. Building an app that constantly evolves is never trivial.

Re: Things I Believe About Software Engineering

#43

Post by BigJono » Mon, Feb 03, 2020, 11:01 AM UTC

imgabe wrote: post #27

tn890 wrote: post #23

Earlier quoted context omitted.

>Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good. What would be the quintessential differences here? We plan, we test, we revise. I'd argue we're all doing the same thing, but if…

The difference is measuring and quantification. Engineering means you know, or can estimate, a load and perform calculations to see if your design meets that load. Most food order apps seem to be more like, eyeball it, slap something together, then it works until it doesn't, at which point you figure out a fix. That works for a while until something else breaks, so you patch a fix into that. Ad infinitum.

Funny you mention food order apps. UberEats web app is my prime example of how a flaming train wreck can make you a ludicrous amount of money, and how there's almost no correlation between engineering quality (not necessarily product quality) and revenue.

Re: Things I Believe About Software Engineering

#44

Post by diffeomorphism » Mon, Feb 03, 2020, 11:04 AM UTC

tr1coder wrote: post #6

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive h…

> Would this eventually lead to 8 productive hours?

In same way that sleeping 10 minutes less each day leads to you not needing sleep at all or showering at 1 degree more each day makes you impervious to boiling water. So, no, absolutely not and potentially dangerous to your health.

Re: Things I Believe About Software Engineering

#45

Post by makach » Mon, Feb 03, 2020, 11:06 AM UTC

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

I am always amazed when I think about how many instructions a computer goes through every time it does a cold-start and the first pixel is shown on a screen. I particularly liked that you wrote "most worked correctly".

Re: Things I Believe About Software Engineering

#46

Post by scoutt » Mon, Feb 03, 2020, 11:06 AM UTC

mrkeen wrote: post #38

scoutt wrote: post #13

Earlier quoted context omitted.

Yeah, I think the author is being a little pessimistic here, but for the benefit of the doubt it may be interesting to understand what correct means in that sentence. I mean, if correct = 100% uptime, 100% effectiveness, etc., then it's not so much of a software problem, but a hardware one.

Yeah but software fails so often and repeatedly that it's rarely worth asking the question "is it software or hardware?"

Exploding batteries, bad wiring, design faults, silicon bugs and erratas, bad connectors, temperature problems... I've seen them all. It's more common than one may usually think, especially if you work in embedded. And somehow I wanted to tie the answer with the concept of the parent about space equipment.

BTW, "is it software or hardware?" is exactly what the boss asks first when a customer has a problem.

Re: Things I Believe About Software Engineering

#47

Post by skolsuper » Mon, Feb 03, 2020, 11:06 AM UTC

BigJono wrote: post #36

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. This is an interesting one. I first took it to mean 'current testing practices are inadequate', which isn't an extreme opinion, and one I bet 99% of HN agrees with. It's 'common wisdom' that teams should be doing more testing, TDD, etc. But now that I read it again, it's spec…

High test coverage is mainly useful for code that will be worked on by more than one person, so it makes sense that you wouldn't want to add it to your personal projects. Doesn't mean it's not worthwhile.

Re: Things I Believe About Software Engineering

#48

Post by LandR » Mon, Feb 03, 2020, 11:07 AM UTC

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

Most software is bad because most developers are bad.

I don't think it's more complicated than that.

Re: Things I Believe About Software Engineering

#49

Post by ehnto » Mon, Feb 03, 2020, 11:08 AM UTC

scoutt wrote: post #13

mtrycz2 wrote: post #8

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. Bullshit. Humans have been sending computers into space for decades, and while yes, some have had programming problems, most worked correctly, for a very specific definition of correctly. Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have appr…

Yeah, I think the author is being a little pessimistic here, but for the benefit of the doubt it may be interesting to understand what correct means in that sentence. I mean, if correct = 100% uptime, 100% effectiveness, etc., then it's not so much of a software problem, but a hardware one.

All uptime problems I have ever encountered were software related. It was just a matter of time before the software failed, but it would eventually fail in some way. The hardware was just doing what it was told to do.

Re: Things I Believe About Software Engineering

#50

Post by ehnto » Mon, Feb 03, 2020, 11:10 AM UTC

scoutt wrote: post #46

mrkeen wrote: post #38

Earlier quoted context omitted.

Yeah but software fails so often and repeatedly that it's rarely worth asking the question "is it software or hardware?"

Exploding batteries, bad wiring, design faults, silicon bugs and erratas, bad connectors, temperature problems... I've seen them all. It's more common than one may usually think, especially if you work in embedded. And somehow I wanted to tie the answer with the concept of the parent about space equipment. BTW, "is it software or hardware?" is exactly what the boss asks first when a customer has a problem.

Regarding my reply to your parent comment, it sounds like we are both biased by our experience, we might need some data!