I've made numerous rebuttals (many right here on HN) to claims that software development is not engineering, citing aerospace examples to the contrary. Often the actual task of programming is as simple (or even simpler) than web programming, but there is a wealth of process that surrounds it, to, as you suggested, make sure that what goes out the door is as correct as possible the first time.
Having also done some web and mobile development on the side, I see software development across a spectrum: ranging from throwaway hacks to cheesy mobile entertainment software to quality mobile entertainment software ... etc ... to embedded medical software and flight control software and such.
While all of these activities are software development, it would be erroneous to classify them all as the same thing. Best practices in one region of the spectrum may well be ludicrous if tried in another region.
How to get into aerospace? Apply for a job? Anyone with a computer science degree or equivalent experience [though the degree may be "required", depending on the company] would qualify for an entry-level position in most aerospace fields that I am familiar with. Another approach, if you're more web savvy, might be to get a job in an aerospace IT department doing internal web development and such, and then transfer out into some other project later.
> I write software that runs on various jet engines. There is a lot of software that goes onto a modern commercial engine, but the general theme of the software I focus on is the modeling of the underlying engine dynamics using sensor data. It's very math- and physics-based. A thorough knowledge of linear algebra, signal processing, regressions, and clustering/neural network algorithms is essential, among other things.
> I've made numerous rebuttals (many right here on HN) to claims that software development is not engineering, citing aerospace examples to the contrary.
I don't get this pattern of argument. If the question is "is programming math" or "is programming engineering," it is not an answer to point out that some programming tasks require engineering or math skills. Doesn't this simply establish that certain problem domains require those skills while others don't? The same pattern of argument could be used, I would think, to "demonstrate" that writing is math or engineering: after all, if you're writing a textbook on engineering you sure need to know something math and engineering. But surely nobody would accept that writing, therefore, IS either of those things. Or pick another social science: knowledge of math sure does help if you want to perform a quantitative sociological study, but I don't think that this makes sociology math.
One might make a somewhat stronger claim about programming: math and engineering skills will make anyone a better programmer. I think this is probably true, to some extent, and this is what is at issue in the articles' debate over the usefulness of mathematical measures of complexity. But this also does not establish that programming "is" either a branch of math or engineering.
Then again, I really have no idea what turns on any of these distinctions or, therefore, why we would be debating them for any reason beyond philosophical curiosity. Isn't it enough to say "no, programming isn't math [or engineering], but like many other disciplines, programming bears some conceptual similarities to math, and a grasp of mathematics [or engineering] will make you a better programmer"?
Well, somewhat notoriously, there has been a rolling debate for better than a century now over whether "higher" sciences simply are complex subdiciplines of "lower" sciences. E.g., are all biologists ultimately just physicists? How about psychologists? Economists? The proper meaning of "are" itself in that sentence also, rightly, is the subject of significant dispute. But the analogy isn't the best since I think that philosophers enjoy that question a lot more than actual scientists.
A more interesting example may be law and economics. There has been a concerted movement by certain economists/legal theorists to show either that law is simply applied (or misapplied) economics, or that it should be. (Here's a taste: http://www.law.berkeley.edu/faculty/cooterr/PDFpapers/stratc...) Again, though, the analogy is imperfect. I don't think that many would claim that law "is" economics, but rather that legal rules are or should be explicable in strictly economic terms. Though maybe this would satisfy some definitions of "is."
Pharmacutical research and clinical trials is another field in which software development is more like proper engineering. I worked in a niche that was not very math heavy, but intensely process heavy (out of necessity). First you design a system that can never fail. Then you assume it will fail and design another system to make up for it. Repeat over and over until you reach the desired safety.
I think the dividing line between whether an industry practices programming or engineering is the question "Is it possible people might die as a direct consequence system failure?" Eventually, someone will die and folks will search for answers. When the investigators/plaintiffs come around, you must be able to produce documentation explaining why you thought your system was robust enough to rely on for a safety critical task.
Edit: Perhaps a good rule of thumb to distinguish between programming and engineering is this: are you productively working full-time and producing more than 20-50 lines of high-level language code per day? If yes, you are programming. If no, you are engineering.
I think the dividing line between whether an industry practices programming or engineering is the question "Is it possible people might die as a direct consequence system failure?"
Commercial aviation products are developed according to the requirements of DO-178B (or increasingly, DO-178C) which defines several levels of criticality at which a software component could exist. The most severe indicates that software failure could result in loss of life. The least severe indicates that a software failure wouldn't interrupt anything notable (often used for in-flight entertainment, for example). As you go up the chain, the amount and stringency of process increases.
> Edit: Perhaps a good rule of thumb to distinguish between programming and engineering is this: are you productively working full-time and producing more than 20-50 lines of high-level language code per day? If yes, you are programming. If no, you are engineering.
I like this. As a web developer I am often expected to write closer to an order of magnitude more lines per day than that. But maybe our high level languages aren't high level enough and I'm mostly writing bloat.
I've made numerous rebuttals (many right here on HN) to claims that software development is not engineering, citing aerospace examples to the contrary. Often the actual task of programming is as simple (or even simpler) than web programming, but there is a wealth of process that surrounds it, to, as you suggested, make sure that what goes out the door is as correct as possible the first time.
Having also done some web and mobile development on the side, I see software development across a spectrum: ranging from throwaway hacks to cheesy mobile entertainment software to quality mobile entertainment software ... etc ... to embedded medical software and flight control software and such.
While all of these activities are software development, it would be erroneous to classify them all as the same thing. Best practices in one region of the spectrum may well be ludicrous if tried in another region.
How to get into aerospace? Apply for a job? Anyone with a computer science degree or equivalent experience [though the degree may be "required", depending on the company] would qualify for an entry-level position in most aerospace fields that I am familiar with. Another approach, if you're more web savvy, might be to get a job in an aerospace IT department doing internal web development and such, and then transfer out into some other project later.