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

61–70 of 231 posts

Re: Things I Believe About Software Engineering

#61

Post by bartread »

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…

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

You are, of course, absolutely correct. Context is key here: you treat software engineering like "real" engineering when it's appropriate to do so (space flight, aircraft control systems, nuclear power plant monitoring and control, medical devices, and so forth).

However, I think for many organisations - and for much of the time - the engineering aspect is often heavily overplayed, and actually you're trading that off against two key aspects of software that can be used to build a real competitive advantage. Those being (i) speed of implementation, and (ii) malleability. Building software can get you to a solution very quickly. You can also iterate or modify that solution very quickly.

Clearly there are limits to this but for many companies, and most startups, getting something working quickly, and iterating on it quickly is far more important than any engineering merit. Same goes for larger companies introducing a new product: don't overegg the "engineering" because it will slow you down and time may be the only sustainable competitive advantage you have.

There's a time to be an engineer, and there's a time to be a cowboy hacker (and everything in between). The real trick is in knowing where on the spectrum to execute in the context of the customer base you're serving and the software you're building.

Re: Things I Believe About Software Engineering

#62

Post by bilekas »

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.

> 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/Whoever is pushing the change.

Re: Things I Believe About Software Engineering

#63

Post by C4stor »

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…

Except that for a lot of developers, "the right thing" has nothing to do with what customers want, but rather with language used, libraries used, CI/CD setup, monitoring active... So many technical aspects that sometimes have nothing to do with the customer wants. And that's where being aligned makes sense.

Re: Things I Believe About Software Engineering

#64

Post by neilwilson »

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 space) and the process (spread out in time) as trivial as possible."

As Systems Engineers we're probably better than 99% of the population at visualising the dynamics of the system, and even then we're still pretty bad at it.

Humility in the face of this human limitation helps enormously I find.

Re: Things I Believe About Software Engineering

#65

Post by dsego »

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'm working on something that's been de-risked. I know what I need to do and I know how to do it

Thanks for including this one. I think the biggest stresses in my dev career have come from times where I didn't really know what needs to be done or when I was way out of my depth. I believe this reason alone was a huge driver of my procrastination in the past, especially when I was the lone programmer on the project.

Re: Things I Believe About Software Engineering

#66

Post by WJW »

onion2k wrote: post #41
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…

most worked correctly, for a very specific definition of correctly. That doesn't mean incorrectness isn't there. That means the circumstances necessary for any incorrectness to manifest in a measurable way didn't happen.

Perhaps, but that is true for any form of engineering. There is no building on earth that can withstand impacts by Texas-sized meteorites, making them incorrectly constructed in those very specific circumstances. Correctness is whether it performs to the requirements of the spec, and if that spec contains tradeoffs that accept non-functioning in certain extreme circumstances then not functioning in those circumstances is NOT incorrect behavior.

Re: Things I Believe About Software Engineering

#67

Post by scoutt »

ehnto wrote: post #50
scoutt wrote: post #46

Earlier quoted context omitted.

Exploding batteries, bad wiring, design faults, silicon bugs and erratas, bad connectors, temperature problems... I've seen them all. It's more common than one may usually think, especially if you work in embedded. And somehow I wanted to tie the answer with the concept of the parent about space equipment. BTW, "is it software or hardware?" is exactly what the boss asks first when a customer has a problem.

Regarding my reply to your parent comment, it sounds like we are both biased by our experience, we might need some data!

I agreed about the bias. When I read "software" I try to think about a broad spectrum of software applications, including the ones that are running in your fridge, router or the ISS.

When author (or most people, I believe) mentions software, it seems it's just apps (like food apps mentioned elsewhere) or web apps, that is just a fraction.

Re: Things I Believe About Software Engineering

#68

Post by cryptica »

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 easily; this is difficult to achieve and most developers/companies fail at that or in the case of companies, they only just barely succeed through the development of extremely expensive solutions.

Big companies like Google don't write efficient software; they use their capital to hire as many expensive engineers as possible to brute force the requirements until it works. That's why they keep rewriting projects from scratch every few years over and over; they don't know how to write adaptable software. Their software is somewhat complex, but still simple enough and they have enough capital so that brute forcing solutions are still feasible (for a high cost).

The same cannot be said about more complex tech like blockchain or large-scale machine learning systems; you can't brute force your way to a solution and full rewrites will actually set you back.

Re: Things I Believe About Software Engineering

#69

Post by diafygi »

adrianN wrote: post #39
pif wrote: post #20

Earlier quoted context omitted.

Allocating the correct budget to write non-trivial, correct sooftware is beyond the capabilities of idiot managers.

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.

Re: Things I Believe About Software Engineering

#70

Post by bartread »

> 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 bought the damn product. I.e., we didn't build the right thing. Let's not kid ourselves: aligning and working well together to build the wrong thing is somewhat pointless (granted, you might learn some useful lessons along the way). Now, if you take that team and then assign them to build the right thing you have something really powerful.

Post reply on HN