> 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…
Writing "correct" software is possible IMO, but is it worth it? For most applications, is it worth spending several times more time and resources in order to make it "correct"? I don't think so.
Things I Believe About Software Engineering
31–40 of 231 posts
Re: Things I Believe About Software Engineering
#32Couldn'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…
Re: Things I Believe About Software Engineering
#33Re: Things I Believe About Software Engineering
#34i am selling my gambling strategy for only $100,000 .
if you are interested to buy by holy grail gambling strategy that beat roulette then let me know by sending message to my email advanotech@gmail.com
Re: Things I Believe About Software Engineering
#35Earlier quoted context omitted.
Writing "correct" software is possible IMO, but is it worth it? For most applications, is it worth spending several times more time and resources in order to make it "correct"? I don't think so.
I always wondered where this multiplicative factor of "several times" comes from. In my experience, writing correct software was marginally slower than writing sloppy software as long as most thinking is done with a pen & paper. Would you mind to elaborate a bit more?
Re: Things I Believe About Software Engineering
#36This 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 specifically saying that current testing practices are 'ineffective', not 'inadequate', which would indicate we should be doing less or even none of it. 'ineffective' to me means worse than nothing, since testing, like anything, has a cost. (time wasted, more code to maintain, lower morale etc)
I'm not sure which the author meant. But I do think the latter is a hot take, and I get the feeling I'm in the minority in agreeing with it.
I'm reminded of this PG quote (obviously written a while ago):
"Indeed, these statistics about Cobol or Java being the most popular language can be misleading. What we ought to look at, if we want to know what tools are best, is what hackers choose when they can choose freely-- that is, in projects of their own. When you ask that question, you find that open source operating systems already have a dominant market share, and the number one language is probably Perl."
If I think about what I've written unit tests for at home, that'd be a bunch of maths-y stuff that I was having trouble debugging, and a few functions here and there that I consider 'tricky' and want a bit of extra peace of mind for.
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. 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.
If anyone on my team at work ever said that, everyone would look at them like they just took a shit on the carpet (including me, because I'm happy to smile and nod for the right salary).
Then there's this, from the same essay:
"One difference I've noticed between great hackers and smart people in general is that hackers are more politically incorrect. To the extent there is a secret handshake among good hackers, it's when they know one another well enough to express opinions that would get them stoned to death by the general public. And I can see why political incorrectness would be a useful quality in programming. Programs are very complex and, at least in the hands of good programmers, very fluid. In such situations it's helpful to have a habit of questioning assumptions."
I definitely know a few coders I've worked with who I'd be comfortable raising my views on testing with. We might differ on the details (I quite like browser tests, don't find a lot of value in snapshot testing most of the time, we might unit test a different tiny subset of the app etc), but by and large we'd agree that most common testing is a crock. And coincidentally, they're all the devs that I think write fantastic code, and that I'd happily build a startup with.
Anyway, that's my Thing I Believe About Software Engineering, with a bit more clarification than OP's ones.
Re: Things I Believe About Software Engineering
#37Goodness this is incredibly naive.
It can only be true only if youre working without customers or stakeholders and who the hell works that way other than hobbyists and startups that are indiscriminately wasting other people's money? The vast majority of software I've written (I'm outside the valley) is written for actual paying customers, and it must be "the right thing," ie, exactly what they paid you to build.
Beyond that, if you're, for example, writing an emulator and the emulator works different than the system it's emulating that's a failure no matter how "aligned" your team is. Nobody will buy it and nobody would even use if you gave it away.
Re: Things I Believe About Software Engineering
#38> 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.
Re: Things I Believe About Software Engineering
#39Earlier quoted context omitted.
Writing non-trivial, correct software while not blowing the budget is beyond the capabilities of the human species.
Allocating the correct budget to write non-trivial, correct sooftware is beyond the capabilities of idiot managers.
Re: Things I Believe About Software Engineering
#40> 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…
It's kind of curious coming out of university where I learned about doing requirements properly and up front (which I suspect kind of tends towards a waterfall approach) then comparing that approach to my work now. Project managers constantly change their mind about requirements and then wonder why we're shipping late, although I suspect some of this is not considering failure/bugs when planning. Even when it comes t…