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

81–90 of 231 posts

Re: Things I Believe About Software Engineering

#81

Post by iainmerrick »

reallydontask wrote: post #56
szatkus wrote: post #40

Earlier quoted context omitted.

Because it's much easier to change software than for example a bridge. I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as well.

> I don't see it as a bad thing as long as all sides are aware that changing requirements changes the deadline as well. In my experience, this could not be further from the truth. There is simply no awareness that change remains expensive it's just that now the process allows it without any fanfare whereas before a change was a big deal. Not saying that change requests are the way to go but certainly an understanding…

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.

Re: Things I Believe About Software Engineering

#82

Post by KnobbleMcKnees »

k__ wrote: post #80
mic47 wrote: post #75

Earlier quoted context omitted.

I read it more like this: If you are building right thing, but you are not aligned, then you will not build the right thing and you will fail. But if you are aligned, it's easier to steer the ship closer to the right thing.

Sure. But I've seen too many dev departments building crap over and over again and feeling pretty good about themselves the whole time.

> building crap over and over again and feeling pretty good about themselves

I'm triggered

Re: Things I Believe About Software Engineering

#83

Post by adrianN »

diafygi wrote: post #69
adrianN wrote: post #39

Earlier quoted context omitted.

I'm pretty sure almost nobody wants to pay millions of dollars for a copy of Word that never crashes.

But will they pay millions of dollars for a WiFi firmware stack in energy IoT devices that the grid is increasingly depending on that isn't vulnerable to memory overflows or other hacking vectors? Software is becoming more and more depended on for life and death use cases every day.

Life-and-death software is already regulated fairly strictly and generally has decent quality. But of course the companies developing it also try to cut costs and in the end it's more about checking off boxes to avoid liability than producing correct software.

Re: Things I Believe About Software Engineering

#84

Post by BigJono »

clappski wrote: post #72
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…

> 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 Surely if you were, for example, writing an automated trading system, or something that handles money, or anything that actually impacts the running of a business in a bigger way than the websit…

Of course, those are good examples. And I do write tests for stuff like that. But it's a tiny, tiny part of what the average front-end web app dev is doing on a day to day basis. My claim isn't that testing is useless. It's that you can get 90% of the benefit from doing probably 10% of what the average dev (in my field, YMMV if you're not a FE web dev) is doing at the moment, and the business value of testing falls off a cliff once you hit the low hanging fruit.

Lemme go back to the same PG article, again, cause it's that good.

"A couple years ago a venture capitalist friend told me about a new startup he was involved with. It sounded promising. But the next time I talked to him, he said they'd decided to build their software on Windows NT, and had just hired a very experienced NT developer to be their chief technical officer. When I heard this, I thought, these guys are doomed."

If I walk into an interview at a startup, and they have 100% unit test code coverage with a nice suite of integration and end-to-end tests, snapshot testing, nice contract tests, the absolute works, all for their 50 customers generating $5k monthly revenue, my first thought is they're probably fucked. It might be a really nice place to work, but if I want job security I'd be going somewhere bigger, and if I want shares I'd much rather be in the share house down the road with the guys that polished off 3x as many features in a couple of weekends of hacking.

Re: Things I Believe About Software Engineering

#85

Post by fjfaase »

jerome-jh wrote: post #16
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…

It is said that the Apollo 11 lunar lander computer rebooted twice during the final approach. We could probably not say it was correct, but still it was robust. "for any meaningful definition of correct" sounds a bit to strong as an hypothesis. Maybe we could rephrase: for all piece of software S, there exist a definition of correctness for which S is incorrect. Timings in particular are very difficult to ensure.

I did not reboot. (I think it did not have the capability to reboot itself.) The program alarms indicated "executive overflows", meaning the guidance computer could not complete all its tasks in real time and had to postpone some of them. https://en.wikipedia.org/wiki/Apollo_11#Lunar_descent See also http://klabs.org/history/apollo_11_alarms/eyles_2004/eyles_2... for a detailed explanation.

Re: Things I Believe About Software Engineering

#86

Post by prox »

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…

I really like this quote, and humility in this case helps to more clearly view the problem (and hopefully solve it adequately)

Re: Things I Believe About Software Engineering

#88

Post by sacado2 »

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…

And it's obviously not the developers' fault, but the clients/customers'.

You want a 100% bug-free web browser? OK, so let's define precisely and formally what the browser is supposed to do. Then, you'll sign a very expensive contract, and in 6 months to 1 year, I'll deliver the software, with a formal proof it works as expected. Of course, the requirements won't change during the development process, and any update after delivery will be costly and will take time.

Now, who would want to pay thousands of dollars for a web browser that will be delivered in a year and that will be obsolete as soon as a new fancy web tech will be used everywhere else? I can't really blame the customer/client either.

But the thing is, "agile" requirements rely on craftmanship, not on engineering. You can only engineer durable things. Buildings would crash constantly, too, if they had to be updated each other week, ASAP, and while keeping the costs as low as possible.

Re: Things I Believe About Software Engineering

#89

Post by zcw100 »

onei wrote: post #15
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…

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…

It doesn’t bother me when they change their mind. What bothers me is when they refuse to document it. Every change should be documented. Print it out and get them to sign it. Then when they complain whip out your pile of documents and say, “Here’s where you asked for X, changed your mind to Y, then back to X, then something new to Z. Is that your signature?”

Devs are expected to have a ticket to track everything they do, so should the product managers. There should also be tickets for meetings so I can track how much time was subtracted from development by useless meetings.

Re: Things I Believe About Software Engineering

#90

Post by mrkeen »

jonathanstrange wrote: post #73
mrkeen wrote: post #38

Earlier quoted context omitted.

Yeah but software fails so often and repeatedly that it's rarely worth asking the question "is it software or hardware?"

I wouldn't be so sure about that. My PC has an overclocked AMD processor with 32GB non-ECC RAM (because ECC ram wasn't even available when I bought it, let alone affordable). Even if the software was 100% perfect, such a machine is expected to crash once or twice every year or so under full load just from the failure rate of the chips (cosmic radiation / quantum tunnelling effects). Especially RAM seems to have becom…

What software are you using that once or twice a year doesn't count as "rarely"?

My Viaplay app stops streaming and tells me I'm not connected to the internet several times a day (when I'm obviously still connected to the internet.)

Several times a week my phone's Netflix state doesn't match my TV's state, so I'm either not presented with the controls or when I press them they do nothing.

Cosmic bit-flips are rare enough to be newsworthy. https://www.johndcook.com/blog/2019/05/20/cosmic-rays-flippi...

If the faults were with the hardware, I'd expect the errors to be spread around the software that I use. But Firefox and Gmail always work for me (even if the JavaScript I'm served makes the machine unresponsive), whereas Netflix, Viaplay and HBO constantly misbehave.

Post reply on HN