Things I Believe About Software Engineering • Hacker News Board

Re: Things I Believe About Software Engineering

#121

Post by bluGill » Mon, Feb 03, 2020, 1:00 PM UTC

tn890 wrote: post #23

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…

>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…

Space starts with quality long before testing. They do formal mathematical proofs of their code. They spend a lot more time in code review. Those are just the things I know of without looking it up, I know there are other things they do.

Re: Things I Believe About Software Engineering

#122

Post by bluGill » Mon, Feb 03, 2020, 1:05 PM UTC

skolsuper wrote: post #47

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.

High test coverage is also more important for large projects than small, even when working alone. I never write unit tests for hello world - it would be a waste of time. I will write tests when I'm hacking on a large project even if I'm alone because I know eventually I will make a change that breaks something that used to work.

Re: Things I Believe About Software Engineering

#123

Post by [deleted] » Mon, Feb 03, 2020, 1:05 PM UTC

AstralStorm wrote: post #118

missosoup wrote: post #101

Earlier quoted context omitted.

In sports and esports this is a well known paradigm. The team committing to execute a poorly strategised play, is much more effective than uncohesive action towards a well strategised play. If everyone is on the same page, the execution will be great even if the idea/requirements are not perfect. Which is better than a a perfect idea executed poorly.

Is it though? It's different because eSports involves training. So you're comparing untrained team with a trained one, and as software is not as reproducible, it is not applicable here. I'd recon a team of worse programmers following a great plan will produce worse results than a team of great programmers following no plan.

[deleted]

Re: Things I Believe About Software Engineering

#124

Post by jonathanstrange » Mon, Feb 03, 2020, 1:05 PM UTC

mrkeen wrote: post #90

jonathanstrange wrote: post #73

Earlier quoted context omitted.

I wouldn't be so sure about that. My PC has an overclocked AMD processor with 32GB non-ECC RAM (because ECC ram wasn't even available when I bought it, let alone affordable). Even if the software was 100% perfect, such a machine is expected to crash once or twice every year or so under full load just from the failure rate of the chips (cosmic radiation / quantum tunnelling effects). Especially RAM seems to have becom…

What software are you using that once or twice a year doesn't count as "rarely"? My Viaplay app stops streaming and tells me I'm not connected to the internet several times a day (when I'm obviously still connected to the internet.) Several times a week my phone's Netflix state doesn't match my TV's state, so I'm either not presented with the controls or when I press them they do nothing. Cosmic bit-flips are rare en…

Let's not turn this into a discussion of the meaning of "rare". We don't disagree, I believe. Sure, software bugs are more frequent. The point is merely that non-ECC RAM is fairly buggy by design and no amount of software will eradicate the crashes due to RAM faults. If you have 32GB or 64GB of RAM these should appear not too rarely, provided you actually use that RAM. Standard desktop CPUs also have surprisingly high error rate, but it's hard to find good figures. I've tried to find some, but apparently Intel & Co. hold them under wraps nowadays.

Re: Things I Believe About Software Engineering

#125

Post by ojilles » Mon, Feb 03, 2020, 1:08 PM UTC

_petronius wrote: post #3

einpoklum wrote: post #2

> Being aligned with teammates on what you're building is more important than building the right thing. So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Strongly disagree with that. > Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Here I mostly agree. The thing is, that you don't know in advance when…

> So, let's cave in to peer pressure or management dictates and continue down the wrong path (technically/socially)? Seems like a very unfair restatement of what the author said. I would read that as "it's more important that everyone has a common understanding of what you are building than it is to spend time worrying about whether you have the exactly perfect goal." Or to phrase it another way: if the understanding…

It's also a reflection (or assertion?) that software development largely is a team sport, not an individual one.

Re: Things I Believe About Software Engineering

#126

Post by diafygi » Mon, Feb 03, 2020, 1:15 PM UTC

adrianN wrote: post #83

diafygi wrote: post #69

Earlier quoted context omitted.

But will they pay millions of dollars for a WiFi firmware stack in energy IoT devices that the grid is increasingly depending on that isn't vulnerable to memory overflows or other hacking vectors? Software is becoming more and more depended on for life and death use cases every day.

Life-and-death software is already regulated fairly strictly and generally has decent quality. But of course the companies developing it also try to cut costs and in the end it's more about checking off boxes to avoid liability than producing correct software.

Hmmm, on the sliding scale of harmless to life-and-death software, it seems that as time goes many programs and services migrate from being closer to the harmless end to bring closer to the life-and-death end.

I feel that migration is often ignored or discounted. For example, Facebook in the early years was considered mostly harmless, but now has migrated to being exploited by state actors to brainwash populations into hating each other, interfering in elections, or at worst performing genocide on a minority group. We need to stop assuming that just because a software application is harmless now, that it will stay that way, and we need to adjust its "correctness" accordingly as it migrates along the harmless life-and-death scale.

Re: Things I Believe About Software Engineering

#127

Post by cambalache » Mon, Feb 03, 2020, 1:17 PM UTC

EnderMB wrote: post #59

I clicked this expecting an overly opinionated list on how to do things the right way, but came away agreeing with nearly everything said. > Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species. This is the one point I somewhat disagree with, and it leads to one of the things I believe about SE - it's all about perceived risk.…

To offer an opposite position I pretty much disagreed with --or at least would heavy qualify-- with most points. The rest I thought were trivial.

> Writing non-trivial software that is correct (for any meaningful definition of correct) is beyond the current capabilities of the human species.

   Perhaps, but this is a worthless distinction, especially if the author does not define correctness. If it is mathematically correctness he is after I think experience has shown a program does not to be correct to be very very useful, and except for extremely critical situations is not a consideration. The same way a road does not need to be perfect.

> Being aligned with teammates on what you're building is more important than building the right thing.

   Hell no! Every leader would prefer to go in the right direction at 50% of maximum speed, that going 100% in the wrong direction.

> There are many fundamental discoveries in computer science that are yet to be found.

   True, but trivial. The same thing can be said about every theoretical branch of science like math and logic, and even for many experimental branches.

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours.

  Perhaps, but if you work the other 4-6 hours at 25% of your peak you still would do more than double during the day. Besides, the 2-hour figure, although reasonable strikes me as anecdotic at best. If anyone knows about a study I would love to read it.

> Most measures of success are almost entirely uncorrelated with merit.

  Without a definition of merit, this is worthless. And for that matter, a definition of success is also needed.

> Thinking about things is a massively valuable and underutilized skill. Most people are trained to not apply this skill.

  Really? Thinking is a valuable skill?, who would have thought?

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry.

  Or perhaps reaching that "effective" threshold is beyond human capacity. I think this claim is pretty insulting to the software industry in general too.

> How kind your teammates are has a larger impact on your effectiveness than the programming language you use.

  Perhaps? It is not that straightforward. Doing a CRUD app with Ruby in a team full of assholes will have a "larger impact" than doing in on assembler with a bunch of goodie-goodies.

> The amount of sleep that you get has a larger impact on your effectiveness than the programming language you use.

  Perhaps? Without further qualifying it is worthless.

Re: Things I Believe About Software Engineering

#128

Post by 6510 » Mon, Feb 03, 2020, 1:17 PM UTC

k__ wrote: post #80

mic47 wrote: post #75

Earlier quoted context omitted.

I read it more like this: If you are building right thing, but you are not aligned, then you will not build the right thing and you will fail. But if you are aligned, it's easier to steer the ship closer to the right thing.

Sure. But I've seen too many dev departments building crap over and over again and feeling pretty good about themselves the whole time.

I wonder how few wrote something that in their own opinion wasn't crap and did something impressive.

Re: Things I Believe About Software Engineering

#129

Post by est31 » Mon, Feb 03, 2020, 1:21 PM UTC

bob33212 wrote: post #54

jwr wrote: post #24

Couldn't agree more with every point listed. These are fantastic points. I do not know the author, but reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now. I expect that especially his first point (about being humble in the face of software systems complexity) will provoke many hubris-filled comments. I fully agree with the author: we are incapa…

autonomous driving is a great example here. It will never be "correct" because there will always be accidents. So the author is right about that. But it is very possible that those cars may be 10x safer than the average human driver some day.

What if you are an above average driver? Maybe for most people it would be an improvement in security, but for you it'd be more dangerous to be in an autonomous car.

Re: Things I Believe About Software Engineering

#130

Post by marcinzm » Mon, Feb 03, 2020, 1:22 PM UTC

bartread wrote: post #70

> Being aligned with teammates on what you're building is more important than building the right thing. I don't buy this. I'm not sure these two things should be placed in opposition (or at least tension) in this way. It makes for a nice soundbite but I don't think it withstands scrutiny. I've seen and worked in teams where alignment was great and we all worked really well together but, at the end of it all, nobody b…

>Now, if you take that team and then assign them to build the right thing you have something really powerful.

Except if not aligned then the team won't actually build the right things but their own personal conflicting views of the right things.

Alignment and having a team that values the right things are not opposites. However, if a team doesn't value the right thing then trying to force them to won't achieve anything.