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

111–120 of 231 posts

Re: Things I Believe About Software Engineering

#111

Post by marcosdumay »

veeralpatel979 wrote: post #19
tr1coder wrote: 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…

For me, I think I can achieve 8 hours if: - I'm working on something I'm interested in - I feel like there's upside for me if the project succeeds - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office - It's a quiet area where I won't have people interrupting my flow state - I'm not blocked on things I need to know - I'm working on something…

> - I can work in different places throughout the day, like my desk, my sofa, in another room, etc. Not really possible in an office

> - It's a quiet area where I won't have people interrupting my flow state

It's amazing how much an office fights against productivity.

Re: Things I Believe About Software Engineering

#112

Post by AstralStorm »

barrkel wrote: post #32
jwr wrote: 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 have a different expectation of correctness; absolute correctness is impossible, in practice correctness is not a binary condition. Even if something provably executes correctly according to spec, the spec may be wrong (and probably is, since everything interfaces with humans eventually). Everything is in a process of becoming; 100% correctness is not achievable, but it's not desirable either - it costs too much; i…

The proper goal is robustness. It is either achieved via clear indication of failure and guidance on alternative solutions - so that the user can handle it. Or by actually failing gracefully and handling as many error conditions in an always reasonable way.

Usually letting user handle it is more general as long as the failures are rare enough.

Internal correctness is perfectly achievable though. External (correct spec) is not.

There are always some unhandled conditions, due to hardware or external component failures...

Re: Things I Believe About Software Engineering

#113

Post by sokoloff »

zcw100 wrote: post #89
onei wrote: post #15

Earlier quoted context omitted.

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…

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

Re: Things I Believe About Software Engineering

#114

Post by cixter »

EugeneOZ wrote: post #77

> The fact that current testing practices are considered "effective" is an indictment of the incredibly low standards of the software industry. It's not tests' fault that programmers are lazy and write tests not for every function, or write unit tests without integration tests or write vice versa. Whole article is just low-quality whining.

woosh

Re: Things I Believe About Software Engineering

#115

Post by arexxbifs »

jonathanstrange wrote: post #96
arexxbifs wrote: post #71

Earlier quoted context omitted.

I've seen the claim before that it was better in the olden days and that "no real engineer" would create software bugs, especially in connection with space flight. Meanwhile, here is a list of space flight software bugs that has cost over a billion dollars and put human lives in jeopardy: https://en.wikipedia.org/wiki/List_of_software_bugs#Space

> I've seen the claim before that it was better in the olden days and that "no real engineer" would create software bugs But who would claim that seriously? That would be obvious hyperbole. The claim is rather that certain teams of engineers have created software/hardware combinations that, for all we know and for all practical purposes, did not have a bug and have not failed due to software error. The development of…

I honestly think the post I commented on more or less made this claim by calling the original statement "bullshit", writing off billion-dollar crashes and real risk of death as "programming problems" and calling it "actual engineering".

All humans are capable of unkowingly making mistakes which can have dire consequences. We've yet to see an approach to software development that will, without a shadow of a doubt, erradicate the possibility of bugs.

Re: Things I Believe About Software Engineering

#116

Post by C1sc0cat »

sacado2 wrote: post #88
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…

In the early days of the web 94 I worked on web project for British Telecom.

I was told that some one had said well this protocol is all very well but we need to build our own slightly different improved version.

Luckily this was stomped on from a great Hight by senior people at BT Labs

Re: Things I Believe About Software Engineering

#117

Post by C1sc0cat »

szatkus wrote: post #40
onei wrote: post #15

Earlier quoted context omitted.

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…

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.

Bridge tolerances are measured in cm, and I suspect that the contractor does make changes on site from the original design the consulting engineers delivered.

Re: Things I Believe About Software Engineering

#118

Post by AstralStorm »

missosoup wrote: post #101
bartread wrote: post #70

> Being aligned with teammates on what you're building is more important than building the right thing. I don't buy this. I'm not sure these two things should be placed in opposition (or at least tension) in this way. It makes for a nice soundbite but I don't think it withstands scrutiny. I've seen and worked in teams where alignment was great and we all worked really well together but, at the end of it all, nobody b…

In sports and esports this is a well known paradigm. The team committing to execute a poorly strategised play, is much more effective than uncohesive action towards a well strategised play. If everyone is on the same page, the execution will be great even if the idea/requirements are not perfect. Which is better than a a perfect idea executed poorly.

Is it though? It's different because eSports involves training.

So you're comparing untrained team with a trained one, and as software is not as reproducible, it is not applicable here.

I'd recon a team of worse programmers following a great plan will produce worse results than a team of great programmers following no plan.

Re: Things I Believe About Software Engineering

#119

Post by EugeneOZ »

bob33212 wrote: post #54
jwr wrote: 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…

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 is a measure for correctness in this case? There are incidents with humans drivers.

Re: Things I Believe About Software Engineering

#120

Post by sime2009 »

astura wrote: post #37

>Being aligned with teammates on what you're building is more important than building the right thing. Goodness this is incredibly naive. It can only be true only if youre working without customers or stakeholders and who the hell works that way other than hobbyists and startups that are indiscriminately wasting other people's money? The vast majority of software I've written (I'm outside the valley) is written for a…

> Goodness this is incredibly naive.

Actually it demonstrates hard earned wisdom.

A team which isn't aligned will only produce a mess regardless of whether their end goal was the right thing.

An aligned team may miss the target but they will be in a position to correct themselves and pursue the target.

Post reply on HN