5 ms·

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 articl

by throwaway2016a 9y ago

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 9y ago
> 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 9y ago
  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 9y ago
  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 9y ago
    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 9y ago
      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 9y ago
        If you read the PE exam for Software Engineering. It is very much that. A lot of process management.
  - jacquesm 9y ago
    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.

jacquesm 9y ago

> 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 9y ago
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 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      If you read the PE exam for Software Engineering. It is very much that. A lot of process management.
- jacquesm 9y ago
  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.