Things I Believe About Software Engineering • Hacker News Board

Re: Things I Believe About Software Engineering

#171

Post by wry_discontent » Mon, Feb 03, 2020, 4:12 PM UTC

antirez wrote: post #169

> There are many fundamental discoveries in computer science that are yet to be found. That's a strange claim. It could be, but there are large evidences that we discover most of the fundamental things immediately up to the 80s, and then the other improvements are kinda really incremental, a program from 1970 is not alien today. Technology of computing progressed a lot more than CS itself, a computer of 1970 kinda is…

Your description of how things are is exactly how Thomas Kuhn describes the process of "Normal Science" in The Structure of Scientific Revolutions. Cracks in our understanding grow, and patchwork theories are put around those contradictions, but eventually the dam breaks and a scientific revolution reshapes the way we think about a subject.

Re: Things I Believe About Software Engineering

#172

Post by groby_b » Mon, Feb 03, 2020, 4:18 PM UTC

est31 wrote: post #161

groby_b wrote: post #135

Earlier quoted context omitted.

If you're an above average driver, a below average driver will ram your car unexpectedly. And there will be nothing you can do, because your reaction times are human. Also, you're likely not as above average as you think yourself to be.

> If you're an above average driver, a below average driver will ram your car unexpectedly. And there will be nothing you can do, because your reaction times are human. That doesn't require level 5 self driving cars, only brake assistants. > Also, you're likely not as above average as you think yourself to be. That doesn't mean that there aren't above average drivers. I'm not assuming I'm among them, but for them, dr…

It requires more than brake assistants. People are, in the limit, idiots (at least when driving). If you drive long enough, you'll see lots of really hair rising things - and the benefit for the above average driver is that the below-average drivers are off the road.

The benefit to self-driving cars is not only that they are driving (hopefully) better than humans - it's also that they minimize the risk of completely erratic behavior. People don't have accidents when they're doing average. They have accidents when they're at their worst.

Last example I witnessed: At a traffic light, a car going ~30mph suddenly and without warning pulls into oncoming traffic because for whatever reason they thought "must left turn" - despite left turns being clearly disallowed.

That wasn't just a "below average driver", because that doesn't happen every day. That was somebody who was very clearly way off their game. And that's the main source of accidents, doing something clearly wrong that you likely wouldn't even think about on a good day. Or being distracted.

Taking these things out of the equation is way more important than "driving better than the best human on their best day".

And this will benefit the above-average drivers as well. (Also, the average will likely move up, so "above average human" might suddenly not mean a lot)

Re: Things I Believe About Software Engineering

#173

Post by patja » Mon, Feb 03, 2020, 4:23 PM UTC

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…

> reading these points makes me suspect he/she is an experienced software engineer that has been doing this for many years now.

And yet, a cursory review indicates they are barely out of high school and has never worked on software in a commercial environment. Not casting stones (I agree with some of what they say too, and what I agree with I find insightful. How's that for confirmation bias?), just observing that this is in fact not based on much experience at all.

Re: Things I Believe About Software Engineering

#174

Post by crimsonalucard » Mon, Feb 03, 2020, 4:36 PM UTC

neilwilson wrote: post #64

I'm with Dijkstra "Our intellectual powers are rather geared to master static relations and ... our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text spac…

Humility should not preclude aggressive problem solving towards eliminating the gap. Be humble and be open to the possibility that this problem can be utterly destroyed.

Have you heard of functional programming?

Re: Things I Believe About Software Engineering

#175

Post by pc86 » Mon, Feb 03, 2020, 4:37 PM UTC

pfarrell wrote: post #147

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)? That's not alignment. For alignment to happen, everybody should be on the same page. And any party can tank this if they refuse to negotiate. I read this as getting alignment between all parties is something that leads to successful projects and therefore is something that should require attention and…

Just make sure you're negotiating the thing you're supposed to negotiate. I've been in meetings where junior or mid-level developers with minimal experience are arguing the merits of the business model with executives. I'm all for asking thoughtful questions but if you have 2 years of experience at a different company in a different industry, saying you don't think Product X is going to make money doesn't really qualify.

Likewise, I wish "business folks"/product owners/whatever you want to call them would give a little more leeway on technical decisions to their technical team. We shouldn't be discussing choice of database tech or service architecture with a VP Finance.

Re: Things I Believe About Software Engineering

#176

Post by pif » Mon, Feb 03, 2020, 4:40 PM UTC

adrianN wrote: post #39

pif wrote: post #20

Earlier quoted context omitted.

Allocating the correct budget to write non-trivial, correct sooftware is beyond the capabilities of idiot managers.

I'm pretty sure almost nobody wants to pay millions of dollars for a copy of Word that never crashes.

I agree with you. And it's ok allocating a limited budget, if you keep in mind that you can get at most a limited software.

In my experience, nearly all delays in software shipments have been only in the eyes of idiot managers: developers and smart managers recognize the constraints being constantly added to a project and know in advance that the result cannot be what was promised in a totally different scenario.

Re: Things I Believe About Software Engineering

#177

Post by crimsonalucard » Mon, Feb 03, 2020, 4:41 PM UTC

jmull wrote: post #134

> Most measures of success are almost entirely uncorrelated with merit. A more important and useful thing to understand is that merit is measured by rules that bubble out of social systems. A mistake you can make is to believe the the rules of merit that you believe are the same ones others believe, that the ones they state are the same ones they actually believe, that the rules don't depend on context, etc. It's har…

I don't agree with 'most.' Our schooling and educational systems are very merit based.

One could say that in the work place, success is uncorrelated with merit.

Re: Things I Believe About Software Engineering

#178

Post by crimsonalucard » Mon, Feb 03, 2020, 4:47 PM UTC

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)?

He didn't say cave in. Your first step in the above scenarios is to get buy in and alignment with management and peers. If you cave in then you aren't in alignment. He is saying the latter event is worse.

Re: Things I Believe About Software Engineering

#179

Post by jgeada » Mon, Feb 03, 2020, 4:51 PM 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 call bullshit on you too. Software is impossible to get correct for the vast majority of cases because there is no specification, nobody even knows or agrees what the specification should be or whether there is even such a thing in the first place. Writing the software is as close as we're ever going to discover a fuzzy description of what the system should be, and the vast majority of the times people change their minds about what they really wanted once they get their hands of that iteration of the implementation. Repeat ad nauseum.

The notion that most(*) any non-trivial program can be formally specified is a myth that largely exists in educational institutions or research institutions disconnected from the realities of production software engineering, and has no basis in real life. Yes, there are a handful of exceptions for extremely constrained control problems in avionics, and even those turn out to have errors in the specification.

Re: Things I Believe About Software Engineering

#180

Post by crimsonalucard » Mon, Feb 03, 2020, 4:52 PM UTC

ryandrake wrote: post #151

clarry wrote: post #137

Earlier quoted context omitted.

I think correctness is achievable for a lot of things, but the industry at large isn't chasing it. People ask for a feature. How long does it take, how much does it cost? Dang, can we get it sooner? Nobody ever asked me about what it takes to ensure it is correct. Nobody asked me to work with them to produce a detailed specification that exhaustively considers all cases that must be accounted for, nobody asked for a…

Exactly. Correctness (and often mere robustness) is almost never a requirement, so it's never even attempted. There are industries where it is important and where it is done routinely, but evidently not in the places most HN commenters work . To say it's impossible probably sounds kind of silly to the engineers who are currently doing it.

Most HN commenters don't even know that correctness is possible.

They don't even know about correctness without testing, they tie correctness and testing together and think it's the same thing.

>There are industries where it is important and where it is done routinely, but evidently not in the places most HN commenters work.

Can you name these industries?