Things I Believe About Software Engineering • Hacker News Board

Re: Things I Believe About Software Engineering

#181

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

0x445442 wrote: post #138

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…

Couldn't agree more but I can say it wasn't just NASA. The industry as a whole used to be more aligned with engineering but this has changed considerably since, say, the rise of "Agile".

> The industry as a whole used to be more aligned with engineering but this has changed considerably since, say, the rise of "Agile".

I'd argue that it changed once smaller businesses could afford (and have room for) their own computer. My best guess would be somewhere around the PDP-8 era (late 1960s-early 1970s).

Once things started to move away from large-scale computer rooms and consoles of blinking lights, towards a more "hands-on" and interactive approach, where the programmer didn't have to wait between "batches" of runs to see what their code did (correct or not), that is when (from a software development point of view) so-called "engineering" went out the window.

Re: Things I Believe About Software Engineering

#182

Post by bartread » Mon, Feb 03, 2020, 4:53 PM UTC

marcinzm wrote: post #130

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

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

Read the remark in context and you'll see that at this point I was talking about a team that is aligned and is building the right thing, and that is really powerful. Sorry if it was expressed clearly enough.

Re: Things I Believe About Software Engineering

#183

Post by crimsonalucard » Mon, Feb 03, 2020, 4:56 PM 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.

"Correctness" in programming refers to mathematical correctness. As in formally proving your program to be 100% correct as apposed to proving your program correct for a couple cases using software blackbox testing.

This can be done and has been done but is not well known among the javascript boot campers that populate HN.

Re: Things I Believe About Software Engineering

#184

Post by NohatCoder » Mon, Feb 03, 2020, 4:59 PM UTC

crimsonalucard wrote: post #177

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.

School and workplace is just an example of two very different merit systems. One is not inherently more right than the other.

Re: Things I Believe About Software Engineering

#185

Post by skywhopper » Mon, Feb 03, 2020, 5:00 PM UTC

crimsonalucard wrote: post #174

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?

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relatively consistent and immutable, but that's only helpful so long as all the rest of your infrastructure is infallible. Which it isn't.

Re: Things I Believe About Software Engineering

#186

Post by bartread » Mon, Feb 03, 2020, 5:05 PM UTC

karmakaze wrote: post #136

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Pair programming can easily double that and the low productivity periods are not nearly as low.

> Pair programming can easily double that and the low productivity periods are not nearly as low.

Pfft. Prove it.

People are very different and work best in different ways. I don't mind pair programming for specific reasons but as a the "normal" way of working? You can keep it.

Pair programming performed relentlessly selects for certain personality types. I, for example, didn't get into programming because I wanted to sit around talking all day. Far from it.

Programming is a creative endeavour, kind of like songwriting. Some people are great solo songwriters, some people work well together, people often struggle to cross that divide and, even if they collaborate well, may struggle to collaborate well with everyone.

I can work effectively in a team but under most circumstances I cannot program at my best with somebody hovering around or buzzing in my ear all time. And, believe me, I am by no means unusual in that regard.

Mandatory pair programming is one of those things that, I think, seems like a good idea to third rate management who don't want to take the time to understand how the people on their teams can work together most effectively.

Re: Things I Believe About Software Engineering

#187

Post by bartread » Mon, Feb 03, 2020, 5:11 PM UTC

PaulStatezny wrote: post #165

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…

> When I'm building web apps at home though, like I always do at work, how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. Serious, not-loaded question for you BigJono: At work, do you (or your team) primarily write unit tests or integration tests? Until my current job, I spent the first 5 years of my career writing unit tests…

I tend to take a similar view.

I will write "unit tests" but they will be at the level of a whole module or assembly, and so often blur the lines with integration tests (particularly because spinning up a test data store is often easier than buggering around with mocks).

"Real" integration tests look at multiple modules or systems.

You catch a lot of bugs this way, have far fewer tests to maintain, and have the freedom to make internal changes without worrying that you're then going to have to fix up 100 tests to get your build working again. And you still get the coverage you need.

It's a better world.

Tbh, I find writing a tests at the class or method level only to be absolutely ridiculous except for cases where I'm dealing with a method that does something particularly tricky or esoteric.

Again, for all this context is key. As developers we should be thinking about what we're doing and the trade-offs inherent in that, not just blindly following a set of rules that say "You should do X; you should unit test; you should write tests for every method of every class."

Re: Things I Believe About Software Engineering

#188

Post by diffeomorphism » Mon, Feb 03, 2020, 5:11 PM UTC

tr1coder wrote: post #140

diffeomorphism wrote: post #44

Earlier quoted context omitted.

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

By the same logic an endurance runner that trains to run 1 km more every few training sessions would end up ...running indefinitely?

Your example is not quite as obviously wrong depending on your definition of "running" and "indefinitely". With a bit of hand waving I would personally count hiking all day, a marathon also feels long enough to me to count as indefinitely. Furthermore, cross-country marathons are a thing, see for example the movie "Forest Gump".

Re: Things I Believe About Software Engineering

#189

Post by smilliken » Mon, Feb 03, 2020, 5:13 PM UTC

skywhopper wrote: post #185

crimsonalucard wrote: post #174

Earlier quoted context omitted.

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?

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relativel…

It's not about eliminating effects! It's about controlling them. A program that had no effect would be perfectly useless.

In distributed systems, it's important to be very intentional about effects, instead of letting them creep into any part of your program.

Re: Things I Believe About Software Engineering

#190

Post by iainmerrick » Mon, Feb 03, 2020, 5:21 PM UTC

peteradio wrote: post #109

iainmerrick wrote: post #81

Earlier quoted context omitted.

Change in a software project definitely isn’t free but I do think it’s fair to say it’s easier than changing a bridge design halfway through. Maybe there’s not as big a difference as people think, though? It occurs to me that is actually possible to change the design of a bridge late in the day. The extra dampers to fix resonance problems on London’s Millennium Bridge are a nice example.

I think there is a bit of respect for the bridge building process not to change it half way through on a whim.

Or maybe bridge engineers are better at pushing back on change requests.

(I don’t actually know which it is; maybe it’s both)