Live data from Hacker News

Things I Believe About Software Engineering

blog.wesleyac.com

151–160 of 231 posts

Re: Things I Believe About Software Engineering

#151
post #137
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 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.

Re: Things I Believe About Software Engineering

#152
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…

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

Re: Things I Believe About Software Engineering

#153
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 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

#155
post #128
post #80

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

Technically maybe.

Re: Things I Believe About Software Engineering

#156
post #62

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

Only some software is that flexible, and then that flexibility will end with the end of support time.

Ultimately all software becomes very inflexible if you cannot get the source code or especially flash firmware.

Re: Things I Believe About Software Engineering

#158
post #145

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

Compare that to the cost of software that works perfectly, but costs 10x what it currently does in order to achieve that perfection. Think of all the free (gratis) software you use that maybe would have a huge cost associated with it to be as reliable as you would like.

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

#159
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…

I would say he/she is an experienced "person", but many of these points, including some about software, can be understood simply by an honest understanding of human beings.

Re: Things I Believe About Software Engineering

#160
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…

How do you known things are correct for NASA and others?
Post reply on HN