this level of rigor always makes me snicker at the engineering in "software engineering"
Also, guess what? The web telescope has a ton of software on it. I suppose that is just "software engineering"? (in quotes, har har)
Look, there are terrible teams doing terrible or very simplistic software work. The same is true in all engineering disciplines and it is of course true that in all engineering disciplines (including software) there are also teams operating with a high degree of passion and rigor in creating very complex things. So yeah, please stop with these silly and really pretty insulting comments.
The ME and EE associated with creating new product like the Nest Thermostat (for example) are, by comparison with something like Grubhub, of trivial engineering complexity (although still very respectable engineering efforts)
What exactly is massively complicated about a predatory aggregator site compared to a vehicle?
I have.
> Let go of your desire to shit on developers
So you're a psychic now, and you read into people's desires by looking at HN posts?
The question remains. But it's clear you can't answer it without ad hominem.
It's a perfectly valid question: what makes an aggregator site like GrubHub a more complex engineering problem than a vehicle?
> maybe it isn't the best comparison, maybe I should have been more specific.
May be it is, may be you should have been, but you weren't
> The point you are asking about in no way affects my larger point so who cares
What is your larger point exactly? That "having a CI" somehow make you an engineer because your software is somehow "more complex than a vehicle"?
> You harping on it is just weird.
The fact that you answered literally nothing, and keep sticking to ad hominem attacks show that you have no substance to what you're saying.
I’m gonna go with Carmack on this one; you think you have a better understanding of it than him? It’s just ifs and for loops.
Sure some contexts require real nuance. But just because Grubhub IS massive doesn’t mean it needs to be engineered that way, that’s a byproduct of socio-political forces (money).
There’s nothing in any science or engineering book I’ve read that says “all software must be engineered as a large distributed application”. Again, a byproduct of contemporary business goals.
My generative art object app is not sending people to the moon and merely relied on me wrapping some well understood math in machine language syntax; it’s librarian work.
Your preference for adverbs and emphasis where you see fit to place it does not move me.
Accomplish something net new for humans, cause I’ve been sending data grams over the internet since the 80s. Grubhub isn’t all that interesting
On that front, the idea that software systems with 100s of features, millions of daily users, extreme uptime requirements, hackers all over the world trying to break in daily , and billions of $$ on the line is "ifs and for loops" or "librarian work" is... oh come on. Never mind, this conversation is silly.
You say you are an experienced developer, but honestly it sounds like you've never built anything except generative art object apps.
"According to Encyclopedia Britannica, the first recorded 'engineer' was Imhotep. He happened to be the builder of the Step Pyramid at Ṣaqqārah, Egypt." [link]
I look forward to drinking ale with Imhotep (and NASA JW Space Telescope engineers) in the great heavenly hall of engineers.
https://interestingengineering.com/the-origin-of-the-word-en...
Yes, it's very different from most software engineering. No need to snicker, just do the appropriate thing for your situation.
Broken software can be fixed cheaply after the fact. Yeah, it’s cheaper if you find the bugs earlier but it shouldn’t come as any surprise that pre-validation is more extensive in systems that are expensive to change.
There are phone note apps and control systems for jets and artificial hearts
You still have SLAs to manage and meet.
How "at best" is interpreted is obviously up to the individual, of course.
But in a world dominated by quarterly earnings this won't fly.
Waterfall works great, if and ONLY if, you know 100% for sure exactly what you're requirements are at the beginning of the project and they never change significantly. This seems to be mostly true-ish for aerospace. Nobody's going to pivot the Falcon 9 into being a washing machine next week.
It seems to me that the point of Agile is that Waterfall fails hard if you have no idea what you want your business software to actually do. Agile is an attempt to build a reasonable software development process around that reality.
So when you get down to it, the lack of rigor isn't so much in software itself as in business. If you don't have any idea what your business is going to actually do, no software or engineering process can fix that.
I may have to borrow that.
An alternative explanation: we're so in a hurry that we don't want to take time out to decide what it is that we are going to build, and so we embrace the fact that we don't know what we are doing and put a sexy label on it, because hey, who doesn't want to be Agile? It sounds so much better than 'clueless'.
If I'm doing a custom project that does some sort of warehouse management for a client, I'm not really deeply invested in my particular vision about how a warehouse should be managed. I'm deeply invested in making my client happy.