As a person who enjoys “shitting JavaScript into containers,” I also think something was lost in the abandonment of UML. There’s something wrong about the fact that software engineering isn’t actually engineering in the traditional sense. Not because we’re not beholden to a monopolistic cabal like the IEEE or bar association, but because it’s always felt like current-form software engineering isn’t actually engineering. The problem space isn’t so different from what it was 30 years ago, yet people solve the same problems over and over again with different tools instead of reducing them to some fundamental principles like UML and working from those. But UML was either the wrong set of principles or came at the wrong time. I like to think software development will revisit something like UML in the future, because there’s just something so compelling about not solving the same problems over and over again in slightly different ways.
> There’s something wrong about the fact that software engineering isn’t actually engineering.
Well, the point is that UML isn't engineering, either. The visual syntaxes are overly baroque, and in many cases add little or nothing over just stating the exact same information in plain text (though there are of course exceptions, where "tracing" linkages visually, looking at containment etc. can actually help when surveying a design).
And the whole OOAD/RUP methodology of "just list plausible 'objects' from the overall problem domain and reflect them directly in the design and implementation" does not exactly help, either. It mistakes what "objects" in the OOP sense are supposed to be used for.
Yeah I agree with you. Clearly something was wrong with UML. I didn't mean something was lost with the abandonment of UML in particular. Just that nothing has come up to replace it and people just write the same code over and over again, poorly. And that there is no real "software engineering" discipline in the same way that civil engineering or electrical engineering exist. I guess it's still just too early in the history of software to really break it down into a discipline.
In mission critical software, software engineering feels like engineering. A friend of mine that has a company focused in this niche jokes around that his IDE is Microsoft Word :)
I think I know what you mean, but could you break that down for me just in case?
And what is mission critical? Aerospace control software? Wouldn’t it be nice if all software was “mission critical”? Not all houses are skyscrapers, but all houses are designed and built to industry acceptable specs and if those specs are wrongly designed or executed incorrectly there are consequences, and rightly so I think.
> Wouldn’t it be nice if all software was “mission critical”
Nope. There are times for nice, strong houses; and there are times for chicken coops made out of duct tape, rusty steel wire and bent nails. As long as they keep chickens in, it is all fine.
It is up to management to decide what kind of structure are they going to build.
That said, there are disturbingly many cases when people don't pay attention to security, and then there are personal data leaks. The handling of personal data should be regulated, verified, and there should be severe consequences for leaks caused by negligence.
As for the rest -- let people do whatever they want. No backups? sure. 'SELECT *' on index.php? you are paying for the servers, go ahead.
> It is up to management to decide what kind of structure are they going to build.
It'd be nice if management was held more accountable when they choose duct tape/rust steel wire/bent nails construction techniques to build multi story apartment blocks instead of chicken coops. But we haven't even solved that problem for actual apartment blocks yet, so I won't be holding my breath for that accountability for software projects any time soon...
The incentives are different. Time to market and exponential growth are not the main concerns. You have financial incentives, enforced by your contract, to deliver documentation and to test every delivery under rigorous QA.
I think this friend is working on satellite software and also (counter intuitively for me) accounting software with anti-fraud semantics.
The Arduino code that blinks my festival costume blinky lights is not mission critical.
The MCAS software on a 737MAX8 should be considered mission critical, but apparently wasn't treated as such at least not by upper management or beancounters who had final say.
NASA's Mars Rover control software is mission critical, and they use coding standards, formal methods, and tools to verify its correctness.
In between is a very very wide grey area. The marketing department thinks the cross domain analytics tracking code on their website is "absolutely mission critical!", but it's built on top of a pile of other people's php and javascript that's way closer to my Arduino blinky light code than to Mars Rovers LOC-4 (Level Of Compliance) or other NASA LOC-5 and 6 code.
Quite what software should possibly be regulated like skyscrapers or houses, and what software should be unregulated like a camp ground, or when that camp ground grows into a shantytown that starts requiring house-like regulation - seems to be a thing that there are no "industry standards" for yet (at least perhaps, cynically, not beyond "maximising shareholder value" or "not leaving money on the table"...)
As you said, mission critical is not always treated as mission critical. Ariane 5 maidens launch failure was due to a software bug. Here some footage from the launch: https://www.youtube.com/watch?v=PK_yguLapgA
Aero space would be considered safety critical, which implies even higher levels of rigor (and regulation). Mission critical can apply to any setting where a lot of money or other resources are at stake wrt. the software functioning correctly.
A lot of companies in that domain also prefer hiring them over CS people, it's a culture thing.
Many of them hired EEs in the 70s/80s (and earlier) who became managers. At the time it made more sense (fewer CS folks) but it established a culture of preferring engineers to computer scientists/programmers/(these days)software engineers. I even left a job because they straight up told me no non-EE would ever become a lead (over a 99% software activity). I appreciated their honesty and found the exit.
The usual justification for perpetuating it has to do with the 1% of the job that touches hardware, but IME it's usually either truly specialized and most of the EEs couldn't do it either, or trivial (following directions from the electrical engineering team that actually designed the hardware).
I think there's value in hiring people who have been trained in a standardized process that prioritizes chains of responsibility, detailed analysis and reliability over velocity, flexibility and bug-tolerance.
Plus, these days, the usual electrical engineering curriculum is ~50% programming, which is more than can be said for some CS curricula (which aren't standardized the way ABET does for EE).
That's a very odd assessment, but that's, like, totally your opinion, man.
> I think there's value in hiring people who have been trained in a standardized process that prioritizes chains of responsibility, detailed analysis and reliability over (velocity, flexibility and bug-tolerance.*
You write this as if that's what CS people are taught (to make crappy systems and crappy code), which may be a common feature of many programmers, it is not the thing they're taught to do in school. At least not if they halfway paid attention.
There's a risk vs productivity balance. Most people develop for systems which are connected to the internet and can be updated on demand, in that case it makes sense to "shit out javascript" because we can go back and optimise and fix things later. That doesn't mean you can't use proper design patterns, but you shouldn't front-load work for something which is most likely going to be wrong for the customer when they see it regardless.
The fact that we can iterate on something once it's released means that engineering in a software sense is different from any other discipline which we call engineering.
On of the main differences is that until things get to the point of being a running system, software is relatively easy to change. It's also a lot easier to test than than, say, airplanes, and the consequences of a mistake are often, but not always, less.
It really isn't. Not when any change can easily be the source of new defects/bugs, and the bugs get exponentially harder and costlier to fix the later they're introduced in the software creation process.
Software is relatively easy to change compared to other engineering disciplines. It isn't universally easy to change, but it is relatively easy to change compared to rewiring a plane to convert from CAN bus to Ethernet or other things. Or changing out the engines on an aircraft. Or changing a bridge's support structure without taking it down.
There's definitely something missing when you don't have a common or standard visual language for communicating ideas between different engineers/teams.
