Live data from Hacker News

Things I Believe About Software Engineering

blog.wesleyac.com

21–30 of 231 posts

Re: Things I Believe About Software Engineering

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

The effort needed to create a "hello, world" program is not trivial. ie, creation of the tool chain (compiler, linker), the OS which to run the "hello, world executable", the text editor to write the code, the code that is in your keyboard, and the list goes on. All software.

No software is trivial if the author wants to broaden his argument to the human species.

Re: Things I Believe About Software Engineering

#22
post #6

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive h…

I tried something like that multiple times - removing all distractions and non work or replacing them by educational activities. Each time it lead to overall slowing down. Peek ceased to be as good. Once it lead to depression, when I replaced all entertainment and chill in my life by "productive activities".

You can do that in short term, the real problem is usually when I tried that for weeks.

Some amount of downtime is necessary. Now I intentionally take breaks and exercise a bit in between coding. The exercise actually helps. With breaks you gotta measure them a bit tho, else you risk taking too long breaks too often.

Re: Things I Believe About Software Engineering

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

>Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good.

What would be the quintessential differences here? We plan, we test, we revise. I'd argue we're all doing the same thing, but if you're working on a food ordering app you can afford not to be as stringent with the testing and quality, versus software that takes people into outer space.

It's just a matter of stronger concerns. Things matter more in a field where you can kill people if you have a bug, so everyone strives to do a better job, top to bottom.

Re: Things I Believe About Software Engineering

#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 incapable of building complex and correct software systems. This is why I am afraid of the hype behind self-driving vehicles.

Re: Things I Believe About Software Engineering

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

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

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

There's a very nice graph on "The Mythical Man-Month" about this.

Basically, if you constrain your software to work for your specific use case, in your specific system, it's "100x" easier.

Also you don't know how many bugs, known or unknown exist in software on space probes.

Re: Things I Believe About Software Engineering

#27
post #23
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…

>Thing is, NASA (and Russian and Chinese and Indian and ...) space engineers have approached their challenges from the point of view of actual engineering, while modern "software engineering" is all about craftsmanship, and just a sprinkle of actual engineering to make ourselves feel good. What would be the quintessential differences here? We plan, we test, we revise. I'd argue we're all doing the same thing, but if…

The difference is measuring and quantification. Engineering means you know, or can estimate, a load and perform calculations to see if your design meets that load.

Most food order apps seem to be more like, eyeball it, slap something together, then it works until it doesn't, at which point you figure out a fix. That works for a while until something else breaks, so you patch a fix into that. Ad infinitum.

Re: Things I Believe About Software Engineering

#28
Based on the title, I was especting yet another opinionated story written by a successful outlier littered with biases, but actually every point resonated with me. Maybe this article illustrates the difference between sharing knowledge and sharing wisdom.

Knowledge can be divisive because it's often communicated through rigid (black or white) statements and founded on outlier experiences but wisdom is generally not divisive; wisdom usually doesn't get people as excited but it's also harder to refute; wisdom is knowledge without the bias. There are plenty of extremely clever (and extremely biased) developers, but very few wise ones.

I tend to think that upvote/downvote mechanisms (Like on Reddit and HN) are somewhat of a threat to the sharing of wisdom because wise ideas don't create that dopamine rush which clever ideas do (they don't trigger the strong feelings required for upvote/downvote). Wisdom is rarely surprising or controversial.

Even discussing the idea of wisdom seems to be taboo. As if it's some kind of outdated concept; but the irony is that it's more relevant now than ever.

Re: Things I Believe About Software Engineering

#29
post #6

> Peak productivity for most software engineers happens closer to 2 hours a day of work than 8 hours. Is it possible to improve this by training? For example if I'm productive 2 hours and force myself to be productive 10-30 more minutes each day for a number of days and when I'm comfortable with 2:30 hours of productivity, force myself to be productive for 30 more minutes. Would this eventually lead to 8 productive h…

It really depends on the context of the work. Usually I'm getting interrupted, or I worry that I'm going to get interrupted. Then there are meetings, coffee breaks between them. All these things prevent me from being productive.

I don't think working 8 hours of productive work will get you to burnout. It's more a matter of habit and discipline and interest in the project.

In my experience, what leads to burnout is a bad working environment and/or working a lot for long period of time.

Re: Things I Believe About Software Engineering

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

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.

Depends on what consequences your software can have in the real world. Most of software that you run on the laptop can glitch and crash all it wants as long as your users can tolerate that, but software for cars for example can have very real consequences on lives.

We should be worried about poor development practices in the automotive industry specifically. Looks like many manufacturers approach the tasks the same way any other hardware manufacturer does, i.e. software is secondary in their minds. Software for a car is kind of the same as software for your next "smart fridge". Among other things, it can be outsourced for example.

Whereas, as Bruce Schneier put it, a modern car is a computer on wheels, not the other way around. A computer on wheels is a lot more dangerous (and there are security implications too, it's what Schneier meant actually).

Post reply on HN