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

Things I Believe About Software Engineering

blog.wesleyac.com

Post reply on HN
Print view View original

161–170 of 231 posts

Re: Things I Believe About Software Engineering

#161

Post by est31 »

groby_b wrote: post #135
est31 wrote: post #129

Earlier quoted context omitted.

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.

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, driving in a self driving car would make matters worse.

Re: Things I Believe About Software Engineering

#162

Post by dschadd »

AJRF wrote: post #154

> "Read the classics. So many “new” ideas in software development have actually been around for decades." From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... What would HN say are the "classics"?

Pragmatic Programmer and Code Complete are usually mentioned as classic programmer text books. I own both and have probably read 10 pages between the 2 books.

Re: Things I Believe About Software Engineering

#163

Post by stronglikedan »

AJRF wrote: post #154

> "Read the classics. So many “new” ideas in software development have actually been around for decades." From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... What would HN say are the "classics"?

I don't know if it's a "classic", but I recently picked up a copy of Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms [0] after reading through another HN thread on good software dev books. I haven't cracked it open yet though.

[0] https://books.google.com/books/about/Wicked_Problems_Righteo...

Re: Things I Believe About Software Engineering

#164

Post by vbtemp »

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…

Having started my career in spaceflight software engineering, I can 100% confirm this comment is correct.

Having now left the field, working on most other software systems and teams tends to basically be "code-til-it-kinda-works" (despite the paeans to "Agile"). It's been amazing how just applying a little bit of the rigor I developed from earlier on in my career from working on embedded flight systems pays incredible dividends later on.

That said, one should have no illusions that NASA is this wonderful hub of innovation and a model for organizations to emulate. Not at all. Definitely not. But there is something to learn from a track record of consistent success flying computers deep in space.

Re: Things I Believe About Software Engineering

#165

Post by PaulStatezny »

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 in OOP systems where I injected mocks of dependencies. I realized in hindsight that these are basically useless. You end up proving very little about the code.

At my current position, we do primarily integration tests. (Have a test DB, essentially run code "end to end" minus the HTML UI.) These tests are _very_ helpful. Have stopped me from creating bugs dozens to hundreds of times. (Over a few years.) Same with other co-workers.

It's worth mentioning the product is a large monolith though.

Re: Things I Believe About Software Engineering

#166

Post by falcolas »

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…

If you have to qualify your statement with hedge words like "most" and "for a very specific definition" then it's hardly "bullshit".

Especially with the plethora of stories about fixing bugs in probes mid-mission, crashes due to poorly sanitized inputs, and byzantine failure conditions.

Re: Things I Believe About Software Engineering

#167

Post by varrock »

stronglikedan wrote: post #163
AJRF wrote: post #154

> "Read the classics. So many “new” ideas in software development have actually been around for decades." From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1... What would HN say are the "classics"?

I don't know if it's a "classic", but I recently picked up a copy of Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms [0] after reading through another HN thread on good software dev books. I haven't cracked it open yet though. [0] https://books.google.com/books/about/Wicked_Problems_Righteo...

Can you link the HN thread about good software development books?

Re: Things I Believe About Software Engineering

#168

Post by falcolas »

karmakaze wrote: post #132

> There are many fundamental discoveries in computer science that are yet to be found. Purely in the realm of computer science and has little the no bearing on a software engineering context.

Except when it does. It's not fast, but these findings in CS find their way into general software development. See: Rust, Haskell, Typescript, ML, Ray tracing, and so forth.

Re: Things I Believe About Software Engineering

#169

Post by antirez »

> 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 alien, and a toy.

Re: Things I Believe About Software Engineering

#170

Post by falcolas »

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…

> I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is and what manual testing or browser testing I need to do to clarify it.

I'm with you 100% here. I would even go one step further:

Unit tests, where Bob is writing code to test that the code that Bob writes does what Bob wants it to (that's a mouthful), are pointless. They don't test Bob's assumptions, they don't test for correctness, and they don't test for robustness beyond the corner cases Bob can come up with (if Bob bothers to test robustness beyond ensuring that the coverage metrics hit 100%).

Even if Bob comes back in to refactor the code later, the unit tests begin to fail solely because the code has changed locality. That changed locality means that the unit tests have to change as well, invaliding any usefulness of the original unit tests.

Post reply on HN