[throwaway2016a]

I was expecting an article focussing on how making software is not engineering said to myself, "not this again."

But the article isn't arguing that, the article seems to be arguing we are something more than engineers.

There is a subtle implication that engineers are hyper pragmatic and the only thing that is important is that it works. My wife who is a biomedical engineer and makes robots might disagree. In fact, I don't know many good engineers of any kind that stop at "just working."

I think this artisan argument could also be applied to other types of engineering as well.

However, the title is slightly off, it should probably be "You Are an Artisan, Not JUST an Engineer" --- the two aren't mutually exclusive and the author even acknowledges that in the first paragraph.

[jacquesm]

> But the article isn't arguing that, the article seems to be arguing we are something more than engineers.

But we are not even engineers, let alone more.

There are some people active in the production of software that would qualify as engineers but that's a tiny fraction and they're not going to be found too far from medical devices and aerospace.

[spraak]

In the UK at least, from my experience there, the term 'engineer' is applied to many more people than I would have expected. E.g. "an engineer is coming to look at my boiler". In the US the term 'technician' seems more common/appropriate.

[tjr]

Aerospace software engineer here. :-)

I feel perfectly content to deem my work as "engineering". I can understand why someone quickly whipping up a small web application (which is not to imply that all web applications are quickly whipped up, nor that all web applications are small) might reasonably feel that their work is not engineering.

So since I've also done quick little web applications, what do I think the difference is?

The aerospace work includes precise operational requirements. It includes formal verification tests which demonstrate that the requirements are met. Code is reviewed; documents are reviewed; reviews are reviewed (not joking, though typically only a sampling subset). Code is subject to formal coding standards; code repositories are subject to formal standards; tools for testing software are subject for formal standards (and documented/reviewed/etc. in their own right). Software that goes onto aircraft is tested in simulations; tested in limited on-ground hardware scenarios; tested in extensive on-ground hardware scenarios; tested on board flying aircraft. The entire process (and the following of process) is reviewed. The end product is signed off on, and, for example, in the case of U.S. commercial aerospace, certified by FAA representatives.

Sounds nothing at all like developing web applications!

Or does it?

A consumer-facing startup web application might have little or no requirements. Testing may be ad hoc. Nothing is reviewed. Coding standards don't exist. Does the software seem to do what is intended? Ship it!

But what about web applications for banking? I've never worked in banking, but I suspect the requirements are fairly robust. (And if in fact they are not, they easily could be.) I suspect that tests are comprehensives, traced back to the requirements. (And if in fact they are not, they easily could be.) I suspect that the software goes through several rounds of testing, that code is reviewed, that coding standards are adhered to. Maybe not to the same level as aerospace, but probably pretty solid.

So what?

Is financial software engineered? I would imagine so. Maybe not as strictly as aerospace -- or maybe stricter! I honestly don't know. But I can easily imagine comparable scenarios.

So if we can engineer financial software, can we not engineer productivity software? We sure could! How about social media software? You bet! Even games? Why not?

I think that all software could be engineered. But in fact it probably shouldn't be. If you want to make a change on software on an aircraft, it might be five minutes editing code in Emacs, surrounded by a year of paperwork and process. That'd be ridiculous for an iPhone game. It'd probably be excessive for a financial application, but maybe some measure of that would be appropriate.

Perhaps there is (or should be) a spectrum of software engineering. At one end, we take extreme measures to ensure quality and process, because (literally) lives depend on it. At the other end, we can hack out whatever we want and it doesn't matter. Most software lies somewhere in between. Maybe some of it should consider moving more toward one end or the other. :-)

[Incidentally, it's common to repeat the phrase, "never roll your own cryptography software". I think it would be totally fair to say "never roll your own flight control software" too. But the people actually writing flight control software aren't necessarily top-tier 0.000000001% brilliant developers. They are, though, surrounded by sufficient process and review that their work is nearly guaranteed to be solid by the time it takes to the air. We could probably do something similar with cryptography software, if there were a model in place (and, I reckon, funding in place) for all of the surrounding infrastructure to engineer it properly.]

[throwaway2016a]

People in our own field tend to assume that because there are "software engineers" who are clearly not doing engineering must mean that no software engineers are engineers.

I think a lot of "software engineers" fall under what in another industry would be called a "technician" which muddies the discussion.

Although I'm not sure I'd even put the bar as high as medical, financial, and military.

A sufficiently large web application can indeed require a level of discipline often associated with engineering. The amount of process and control when you have 50 people working on a project and millions of users is very different than the lone hacker in their garage.

You also implied that in engineering making a tiny change can be a year worth of paperwork. While not as extreme as that, if your handling credit card data for instance there is a lot of paperwork, documentation, and verification that goes into pushing a change live.

[tjr]

Something else interesting is that the notion of engineered aerospace software does not necessarily have anything to do with the software itself. A lone hacker in their garage very well could author the exact same software. The difference is in how it was developed, and that there exists a paper trail to demonstrate it was developed and reviewed to sufficient standards. Requirements and tests and reviews don't get installed on the aircraft; the executable object code gets installed on the aircraft.

One might posit that "software engineering" is not very much about developing the actual software at all, but just ensuring that it is done correctly?

[throwaway2016a]

If you read the PE exam for Software Engineering. It is very much that. A lot of process management.

[jacquesm]

I've worked in banking. I (re)wrote a fuel estimation program for cargo aircraft (so software that is used only prior to a flight). Let's just say the two have very little to do with each other when it comes to process and leave it at that.

[tjr]

Do you think that banking software could be developed more like aerospace software?

Do you think that it should be?

[jacquesm]

It could be, and in some cases (for instance the transaction portion, interest calculations) it should be. Reporting and statistics are less important and an error there could be fixed without affecting the balances, especially when it is internal stuff.

[falcolas]

Personally, I've never even had to really consider working around issues like those that are presented here:

https://c3.nasa.gov/dashlink/static/media/other/ObservedFail...

I also don't really consider myself an engineer: I'm self taught, I don't have a degree, I've never had to formally prove my software, and the most failures in my software can cause is some potential loss in revenue.

[grzm]

The quote "There is no such thing as digital circuitry. There is only analog circuitry driven to extremes." is a gem. Thanks for the link! Is anyone aware of a textual version of this slide deck?

https://c3.nasa.gov/dashlink/static/media/other/ObservedFail...

[jacquesm]

That's a fantastic link, thank you for posting. I spent an hour reading that.

[falcolas]

For your enjoyment (there's a couple of other good links in the discussion): https://news.ycombinator.com/item?id=14765868

[brett40324]

Serious question. Can you offer any advice on going from web/mobile app developer to the level of systems/aerospace software engineer? Say, over the course of 5 years?

[tjr]

I'm not sure if you are asking how to transition into working in aerospace? Or how to apply aerospace engineering methods to web/mobile? (Or maybe something else?)

Aerospace development is not categorically harder or more skillful than any other sort of software development. Some areas are math-heavy, but that's true elsewhere too. The biggest difference is the process overhead.

[brett40324]

"I'm not sure if you are asking how to transition into working in aerospace?"

Thanks for responding. Yes that's my question. I assume that domain knowledge in embedded systems, as well as aerospace science are minimum requirements?

[tjr]

For a niche field that programmers rarely ever hear much about, there's quite a breadth of variety.

Lots of people are hired into aerospace straight out of college, with degrees in non-aerospace things like computer science and electrical engineering. A lot of the domain knowledge is hard to come by outside of working in the field, and it's generally not expected for an entry-level role.

But even if not strictly required, some related domain knowledge would sure make you shine as a job candidate. Specifically:

- Lots of software is written in C, C++, or (less often today) Ada. I would suggest focusing on being skillful with C first and C++ second. It would be nice bonus points to at least have some familiarity with Ada, even if the most you ever do with it on the job is read old code. Verification test frameworks will likely be in some high level scripting language; I've seen Python and Lua used, myself. Model-based development tools (like Simulink) are used sometimes too.

- Understanding of real time embedded systems would be great. There are a variety of such systems out there; real-time Linux would be a good option to become familiar with.

- Knowledge of low-level networking concepts. I.e., the bytes that make up UDP packets, TCP packets, packet headers. Whether if you work directly with networking or not, you'll likely encounter "one box sending data to another box" all over in aerospace. Good ol' Ethernet is used, but so are other more obscure protocols like ARINC 429, ARINC 664, MIL-STD 1553, etc. While most of these specs are not available free of charge, they are available to the general public. They're not exactly light reading, though, and I've learned more with the spec in one hand and a packet sniffer on a running system in the other, than trying to comprehend the spec by itself. But Ethernet / TCP / UDP is easy to learn about, so start there.

- Aerospace science? If you went out and got a degree in aerospace science, especially a combination of aerospace and CS, I can imagine companies tripping over themselves to hire you. Do you need it to do the job? Depends on the job. You could have a successful career developing software in aerospace without actually knowing much about aerospace, because there's just so much to do. One developer does the aerospace calculations, and another one tackles making the code thread-safe, and so on. But a solid understanding of aerospace science concepts would make you quite desirable as a candidate, and would open doors for you to work on things that other "CS-only" people don't know how to do. [There are some aerospace classes on edx.org -- if you like online courses, could be a good way to start. The University of Kansas has an extensive program, though I don't think they offer it online.]

- Related, and maybe easier (or maybe harder), would be to learn about flying. A ground school class would be a good start, and can be done online. Holding a private pilot certificate would be some great resume fodder, and would also give you good knowledge for the job. You would have better understanding of another facet of aerospace knowledge, and would also have more of an "end user" kind of perspective. [Look at http://www.kingschools.com/ for some online materials, or try a local flight school. Quick start: try X-Plane.]

Any or all of that would be good material for being a more attractive job candidate. But again, many people get their start without knowing much or even any of that, and pick up what they need on the job, so it's not strictly required. It would just be helpful. And, depending on the job market at the time, it could be extremely helpful.

And to restate my opening remark, there is immense breadth in this seemingly tiny niche field. Due to the very nature of the work, no one person does everything. You would almost certainly not do the aerospace calculations, and do the network programming, and do the verification testing, and do the graphical displays, and do the air-to-ground communication system, and do the ... And that's just for the software! Someone designs the nose cone, and the wings, and the fuel system, and the passenger seating, and the ...

As always, beware career advice from random people on the internet. But I hope you found something helpful here!