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

101–110 of 231 posts

Re: Things I Believe About Software Engineering

#101

Post by missosoup »

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.

Re: Things I Believe About Software Engineering

#102

Post by exdsq »

BigJono wrote: post #43
imgabe wrote: post #27

Earlier quoted context omitted.

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.

Funny you mention food order apps. UberEats web app is my prime example of how a flaming train wreck can make you a ludicrous amount of money, and how there's almost no correlation between engineering quality (not necessarily product quality) and revenue.

> there's almost no correlation between engineering quality (not necessarily product quality) and revenue.

Agreed. Sadly I'm much more interested in engineering quality than revenue..

Re: Things I Believe About Software Engineering

#103

Post by exdsq »

cryptica wrote: post #68
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…

Even the NASA curiosity rover encountered a software error and now it's stuck. I think OP's argument stands. And NASA software is not that complex if you think about it; at least it has fixed requirements; once they ship it, it's done. No more changes. This is different from some complex software which require constant changes and adaptation to changing requirements; in this case the code has to be designed to adapt…

> And NASA software is not that complex if you think about it; at least it has fixed requirements; once they ship it, it's done. No more changes.

Nope, they still make changes. This is a case study for a company that helped debug and fix a low-level C bug on the Mars Curiosity Rover as it was traveling to Mars. https://semmle.com/case-studies/semmle-nasa-landing-curiosit...

I work with high-assurance software in the blockchain space and only recently read a paragraph from some old NASA software quality textbook and thought damn.. this is awesome. It's anything but trivial!

Re: Things I Believe About Software Engineering

#104

Post by tatersolid »

BigJono wrote: post #43
imgabe wrote: post #27

Earlier quoted context omitted.

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.

Funny you mention food order apps. UberEats web app is my prime example of how a flaming train wreck can make you a ludicrous amount of money, and how there's almost no correlation between engineering quality (not necessarily product quality) and revenue.

Uber loses fantastic, mind-bending amounts of money every quarter. Their apps don’t “make money.”

Re: Things I Believe About Software Engineering

#105

Post by bluGill »

bilekas wrote: post #62
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 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…

They are building a bridge over the river near me. Headlines a month ago where that the two ends were within half and inch (1.25cm) of each other - which was considered the best possible case. Last year the bridge contractor build a dozen different adapters plates so cover all possible mismatches so that construction wouldn't slow down when the two ends got close enough together that they could tell how far off they were. (the bridge was supposed to open 5 months ago, but that is a different story...)

I'm not sure what the point is, but it somehow fits into yours...

Re: Things I Believe About Software Engineering

#106

Post by celticmusic »

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…

There were several of the bullet points that I thought fell under this. Nice soundbite, but doesn't really jive with reality.

This one is probably the most egregious though, in that great software is created BECAUSE people aren't aligned and those discussions/fights are had.

Re: Things I Believe About Software Engineering

#107

Post by unnouinceput »

""

You can say this about any tech field. Heck you can say this about social domains as well. And yet world marches over with progress being made.

""

Because yeah, building the wrong thing was always good and had nothing to do with economic failures, right? Tell this also to NASA teams that build the moon race, is littered with teams doing different stuff and not being aligned. My favorite story for that is the one about how they made the suit.

"

There are many fundamental discoveries in all fields that are yet to be found, CS is no more special then Psychology for example, it only pays better these days.

"

Peak productivity depends on each individual and within each individual there are seasons. I can be productive at nights or during day time, and when I am productive during certain hours for the life of me I would not be able to be productive on other hours. Procrastination is perception of individuals during their non-productive hours.

"

Finally, the single statement in this otherwise useless article that I can agree with.

"

That depends on what your education/how your parents raised you. As for how much value this has in current society, well just ask Trump (he's still a billionaire). Also, in that regard see previous point.

"

Actually the standards are quite high, you should've seen them 40 years ago when Ford preferred to allocate 200M USD for paying victims than rather improve its safety when building the chassis, because that would've eaten their profits ten fold.

Become freelancer, be your own boss and you couldn't care less about teammates. One man show where you call all the shots is awesome.

"

This point goes hand in hand with above one about productivity, it all boils down to each individual.

Re: Things I Believe About Software Engineering

#108

Post by mping »

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…

Productivity is a function of concentration and understanding. If you have sufficient knowledge, what lacks is concentration. I'm perpetually amazed how people 1) fail to see this and 2) think their concentration power is fixed for life.

An example of this is when you do pair programming, your pair forces you to keep concentrated (and you force him too) - if you are screensharing you won't alt tab to reddit) so it's an example on how you can keep focused for longer periods than normal, at the expense of being more tired at the end of the day.

Re: Things I Believe About Software Engineering

#109

Post by peteradio »

iainmerrick wrote: post #81
reallydontask wrote: post #56

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

I think there is a bit of respect for the bridge building process not to change it half way through on a whim.

Re: Things I Believe About Software Engineering

#110

Post by fcantournet »

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…

The trick is to define "productive".

The whole point of this is that it's not a binary state, and it's not "writing code". So, tl,dr : no, it's not because you are most likely not the bottleneck. You are not the master of the cognitive overload you operate in for instance.

Post reply on HN