> 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 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…
Things I Believe About Software Engineering
151–160 of 231 posts
Re: Things I Believe About Software Engineering
#152Couldn'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
#153> 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 think this is all based on experience. You know when the tests are going to give you value, because you know when you’ve been burned by a lack of tests in the past. You put tests where you’re worried about bugs appearing.
I write tests when 1) they help me bring up code (you’re gonna do some interactive test/debug cycles in the beginning, might as well do that with tests), or 2) I can’t sleep at night because the code is subtle or complex and I worry about its continued correctness, or 3) there’s a bug and it’s easy to write a regression test for it.
Sometimes writing code without tests is like putting sand into a pile: it works fine for a while, but as soon as you start overloading it, whole faces suddenly shear off. You can shore it up with your hands, but above a certain scale you’re battling to prevent collapse. Tests are like scaffolding you put in place to keep the sand from sliding away.
Re: Things I Believe About Software Engineering
#154From the original post that inspired this post: https://gist.github.com/stettix/5bb2d99e50fdbbd15dd9622837d1...
What would HN say are the "classics"?
Re: Things I Believe About Software Engineering
#155Earlier quoted context omitted.
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
#156Earlier quoted context omitted.
> I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as wel It's extremely dangerous, and software is quite comparable to a bridge. Imagine starting at both sides of the river and the bridge not meeting in the middle. Changin requirements / features is very simular. And while on paper it sound like no problem, thats when you need to push back against your PO/W…
Yes, there are some analogs to bridges, but software is much more flexible than concrete. We can pretend we're building a bridge, but there could be another company, that is more comfortable with changing requirements and may deliver their product later, but more suited to a market.
Ultimately all software becomes very inflexible if you cannot get the source code or especially flash firmware.
Re: Things I Believe About Software Engineering
#157Re: Things I Believe About Software Engineering
#158Earlier 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.
Everyone seems to think that, but I feel this ends up being death by a thousand cuts. I don't know a single piece of software on my computer right now that doesn't crash, act weird, hang or do something else to annoy me on a daily basis. Now yes, each infraction might be just a minor niggle, but god it adds up! By the end of the day, all the bugs that on their own shouldn't be too bad, leave me frustrated as hell and…
It's all about tradeoffs. Everybody wants cheap software that works perfectly, but reality dictates that can't happen. Most of the time, cheap/free with minor annoyances is better than perfect but high-cost.
Re: Things I Believe About Software Engineering
#159Couldn'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
#160> 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…