> It's wildly misleading to use the same word for an app written by a few programmers in a couple of months (like the Iowa Caucus app) and the Space Shuttle control software (maintained by hundreds of people, with an average of 1 bug per release)
You are drawing a distinction here between two vastly different project types—not between the roles of people on the projects.
Of course something that has a million times the budget has the potential for significantly higher reliability.
Additionally, the particular requirements of the space shuttle software project make reliability extremely important.
If a computer programmer were to allocate similar priority to reliability in an app for chatting with friends, I'd argue this would make them less qualified for the title of engineer.
My understanding of what characterizes an engineer is that they make effective decisions about technical tradeoffs, and come up with plans that can be realistically executed while optimizing a set of project requirements (technical and non).
In my experience, software engineers are (often) appropriately labeled as such, insofar as the work they do matches that definition (if the definition is inadequate, that's another matter—happy to hear an alternative).
My hypothesis is that people start getting fussy about the 'software engineer' label for two reasons:
1) There's a lot of variety in software work being done. Not everyone writing code is an engineer. Not sure about the situation at large companies, but at least in the startup world, in my experience, everyone I've worked with who had the title deserved it in the sense that they were doing engineering work according to the above definition.
2) The requirements for software projects—especially in terms of the importance of reliability—are very different from those in more traditional engineering domains, which can create a superficial appearance of poor/non-existent engineering. But this is exactly what you'd get if the engineer did an extremely good job, but with project requirements that don't place high value on e.g. reliability.
It would be great if every app could have formally verified code etc.—but the reason they don't has to do with businesses funding these projects, not with the engineers working on them.
> It would be great if every app could have formally verified code etc.—but the reason they don't has to do with businesses funding these projects, not with the engineers working on them.
You can look at it from the company's point of view: Net profit would go down if they formally validated everything. Put that way, it sounds horribly selfish of the business. But you could also look at it from society's view: Net value to society would go down if everything was formally validated. Why? Because much less software would be created. And, for something like a chat app, we (society) don't actually need the level of reliability that we'd get from formal verification. Don't waste the effort doing it, because it's a net loss. Go spend the time building something else.
The result is that we get chat apps that crash. But we also get much more total stuff. I think that's a net win, even though it's annoying when the chat app crashes.
> If a computer programmer were to allocate similar priority to reliability in an app for chatting with friends, I'd argue this would make them less qualified for the title of engineer.
While it's entirely correct for an engineer to use different materials in different circumstances, I don't think I've seen professional engineers in other fields choose methods which they know will fail under expected stresses simply because it's not considered an important project. There's still a safety factor.
> Of course something that has a million times the budget has the potential for significantly higher reliability.
I've seen software projects with funding everywhere between $0 and $outrageous, and the latter never use their extra funding for reliability. It's always for scope. They build software in exactly the same flimsy way -- just a lot more of it. You never see a press release that says "We took $5M in funding so we can finally upgrade from SCRUM to SEI 3, and fix all those dang bugs."
> I don't think I've seen professional engineers in other fields choose methods which they know will fail under expected stresses simply because it's not considered an important project. There's still a safety factor.
It's not that the project is unimportant so the engineer doesn't care about it, it's that the project's requirements have a certain tolerance for failures. The project dictates that tolerance, not the engineer; the engineer develops and implements a plan that works within the tolerance.
And no, typically there is not a safety factor, which is part of why the tolerance is higher for these projects.
> They build software in exactly the same flimsy way -- just a lot more of it
Again, this is not something determined by the engineers—it's just part of the project requirements the engineers are employed to work from.
I think your gripe is more with something like software product managers than it is with software engineers.
Nobody writes code that fails reliably under expected conditions. Reliability is a question of robustness in the face of unexpected or rare conditions.
BTW, chat apps are a bad example. Not sure why this thread is using them. WhatsApp has higher uptime than the telephone system itself, if I recall correctly. Making highly scalable and available message switches is a solved software/computer engineering problem.
A better example is most bespoke business software. If it collapses in a messy heap because a microservice ran out of disk space, people shrug and put in alerts to make sure disk space doesn't run low again without an operator being notified. Job done. Not exactly a rigorous approach to failure but it'd make no sense to spend weeks or months on making the entire system fail gracefully in that situation when it's easily avoided.
You are drawing a distinction here between two vastly different project types—not between the roles of people on the projects.
Of course something that has a million times the budget has the potential for significantly higher reliability.
Additionally, the particular requirements of the space shuttle software project make reliability extremely important.
If a computer programmer were to allocate similar priority to reliability in an app for chatting with friends, I'd argue this would make them less qualified for the title of engineer.
My understanding of what characterizes an engineer is that they make effective decisions about technical tradeoffs, and come up with plans that can be realistically executed while optimizing a set of project requirements (technical and non).
In my experience, software engineers are (often) appropriately labeled as such, insofar as the work they do matches that definition (if the definition is inadequate, that's another matter—happy to hear an alternative).
My hypothesis is that people start getting fussy about the 'software engineer' label for two reasons:
1) There's a lot of variety in software work being done. Not everyone writing code is an engineer. Not sure about the situation at large companies, but at least in the startup world, in my experience, everyone I've worked with who had the title deserved it in the sense that they were doing engineering work according to the above definition.
2) The requirements for software projects—especially in terms of the importance of reliability—are very different from those in more traditional engineering domains, which can create a superficial appearance of poor/non-existent engineering. But this is exactly what you'd get if the engineer did an extremely good job, but with project requirements that don't place high value on e.g. reliability.
It would be great if every app could have formally verified code etc.—but the reason they don't has to do with businesses funding these projects, not with the engineers working on them.