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

221–230 of 231 posts

Re: Things I Believe About Software Engineering

#221

Post by kikimora »

crimsonalucard wrote: post #216
skywhopper wrote: post #185

Earlier quoted context omitted.

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relativel…

>"utmost to shorten the conceptual gap between the static program and the dynamic process" I'm mostly referring to this part of the quote. Pure FP is basically a static program and not a dynamic process. Nothing is changing in FP, nothing is dynamic. FP makes this gap zero. Outside of FP (the distributed system) is a different story of course.

I think Djeikstra was talking about our limited ability to reason about what program actually does by looking at it source code. FP helps but there is still a long way ahead of us. For example I can create spaghetti code in any language and any programming paradigm. FP helps me to eliminate state, next big thing should help me to eliminate unclear and complex control flow, bad abstractions and clunky API’s.

Re: Things I Believe About Software Engineering

#222

Post by kikimora »

pmiller2 wrote: post #200

Here is my (unpopular? original?) opinion about software engineering: software engineering is more like writing a novel than building a bridge. Bridges are fairly well understood, and the parameters necessary to build them successfully can be approximated very closely once it’s decided what materials to use. Software will surprise you, in the sense of “no battle plan survives contact with the enemy.” You will have ba…

> You will have bad data in prod. Users will do unexpected things. You won’t always be able to reach S3. And, this is all true even assuming the software is written perfectly to spec.

Surprisingly this nonsense happens in a discrete setting where we can (in theory, of course) enumerate all possible inputs. Again surprisingly we cannot find effective way to automagically partition input space into equivalence classes to assist us in testing.

Novel works in conjunction with our brains and it is not surprising that there are no definitive rules or “good novel equation”. But programs implement defined algorithms and super predictable. Yet creating them feels like writing a novel.

I agree with your statement but at the same time it feels wrong that we find ourselves in such position.

Re: Things I Believe About Software Engineering

#223

Post by emmanueloga_ »

andruby wrote: post #58

> Being aligned with teammates on what you're building is more important than building the right thing. I would write this as: Building the right thing wrong is more important than building the wrong thing right. And I firmly believe that agreeing on _what_ you are builing is more important than _how_ you are building it. Mainly because it is easier to change the _how_ than it is to change the _what_.

I read it as:

"Build consensus before you start building any specific implementation".

... the idea being that it is better for a team to collaborate on a compromise solution than any given person pushing into their pet solution because they "know better".

Re: Things I Believe About Software Engineering

#224

Post by Izkata »

fjfaase wrote: post #85
jerome-jh wrote: post #16

Earlier quoted context omitted.

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.

> I did not reboot.

...Got something to share with us?

;)

Re: Things I Believe About Software Engineering

#225

Post by neilwilson »

crimsonalucard wrote: post #216
skywhopper wrote: post #185

Earlier quoted context omitted.

The list of "things I believe" the OP cited mentions functional programming as a fundamental belief as well, because it "eliminates side effects" and doesn't "mutate state". And yet, these traits give us little or no help in troubleshooting problems in distributed computer systems, where side effects are inherent and state is in constant flux. Oh sure, to within the CAP theorem, you can keep your data store relativel…

>"utmost to shorten the conceptual gap between the static program and the dynamic process" I'm mostly referring to this part of the quote. Pure FP is basically a static program and not a dynamic process. Nothing is changing in FP, nothing is dynamic. FP makes this gap zero. Outside of FP (the distributed system) is a different story of course.

The abstraction of FP, which is the same as mathematics, is that all functions can be treated as resolved instantly in time and from a given starting point you'll always get the same answer.

However in the real world things take time and time flows in one direction, and have a nasty habit of being non linear. FP abstracts away these complications with the notion of 'actions' which are then dealt with by some outside 'runtime system'.

Hence System.Time.getClockTime >>= print

Re: Things I Believe About Software Engineering

#226

Post by mtrycz2 »

jgeada wrote: post #179
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…

I call bullshit on you too. Software is impossible to get correct for the vast majority of cases because there is no specification, nobody even knows or agrees what the specification should be or whether there is even such a thing in the first place. Writing the software is as close as we're ever going to discover a fuzzy description of what the system should be, and the vast majority of the times people change their…

Given all of the comments on here, I think I might have not stated the central point clearly enough. It isn't about getting things 100% correct 100% of the time. No engineering does that.

What we like to call "software engineering" isn't actually engineering, and more like a craft than anything. Actual engineering in software is possible.

I take issue with calling our field software engineering. It's a buzzword.

Re: Things I Believe About Software Engineering

#227

Post by crimsonalucard »

neilwilson wrote: post #225
crimsonalucard wrote: post #216

Earlier quoted context omitted.

>"utmost to shorten the conceptual gap between the static program and the dynamic process" I'm mostly referring to this part of the quote. Pure FP is basically a static program and not a dynamic process. Nothing is changing in FP, nothing is dynamic. FP makes this gap zero. Outside of FP (the distributed system) is a different story of course.

The abstraction of FP, which is the same as mathematics, is that all functions can be treated as resolved instantly in time and from a given starting point you'll always get the same answer. However in the real world things take time and time flows in one direction, and have a nasty habit of being non linear. FP abstracts away these complications with the notion of 'actions' which are then dealt with by some outside…

Yes I know about the IO loop. FP reduces the gap to zero when segregated away from IO.

However I literally said for distributed systems this does not apply. This is IO. If you're referring to something like the DOM, the architecture is similar for redux. Within the bounds of IO your program is not dynamic.

Re: Things I Believe About Software Engineering

#228

Post by GuB-42 »

est31 wrote: post #129
bob33212 wrote: post #54

Earlier quoted context omitted.

autonomous driving is a great example here. It will never be "correct" because there will always be accidents. So the author is right about that. But it is very possible that those cars may be 10x safer than the average human driver some day.

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.

Driving ability is almost the perfect case study for Dunning–Kruger effect. Most drivers think they are better than they really are.

So you maybe right in that really good drivers may be safer when in control of the car, but it won't be the case for people who think they are good. And if you leave individual drivers a choice, you can expect to see a lot more of the latter. And, to follow up on groby_b, they are going to ram your car and there will be nothing you can do.

In the end, unless we have a system to reliably select the highest skilled drivers, and making sure they are at the peak of their ability, autonomous cars will be safer for everyone.

Re: Things I Believe About Software Engineering

#229

Post by al_ak »

mtrycz2 wrote: post #226
jgeada wrote: post #179

Earlier quoted context omitted.

I call bullshit on you too. Software is impossible to get correct for the vast majority of cases because there is no specification, nobody even knows or agrees what the specification should be or whether there is even such a thing in the first place. Writing the software is as close as we're ever going to discover a fuzzy description of what the system should be, and the vast majority of the times people change their…

Given all of the comments on here, I think I might have not stated the central point clearly enough. It isn't about getting things 100% correct 100% of the time. No engineering does that. What we like to call "software engineering" isn't actually engineering, and more like a craft than anything. Actual engineering in software is possible. I take issue with calling our field software engineering. It's a buzzword.

Yet formal correctness is about "getting things 100% correct 100% of the time" to the greatest extent possible (you can mathematically prove the "correctness" of a program using formal methods, but it still has to run on actual hardware and you're assuming there are no bugs in your tooling).

Re: Things I Believe About Software Engineering

#230

Post by zcw100 »

sokoloff wrote: post #113
zcw100 wrote: post #89

Earlier quoted context omitted.

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…

Is there anything stopping you from creating those tracking tickets? “MEET-123: zcw attend meeting on XYZ, High, 1hr, Done”

Yes. When your manager comes over and says, “stop tracking meetings or you’re fired”
Post reply on HN