4 ms·

I don't understand why he's drawing this line in the sand. Engineering is applying scientific principles to solve a problem. Development is the process of impr

I don't understand why he's drawing this line in the sand. Engineering is applying scientific principles to solve a problem. Development is the process of improving something. I don't see why they should be at odds; the concepts seem orthogonal. Instead of insulting rigorous, creative professionals who prefer the name "developer" over "engineer", maybe he could have said that he wants to hire people that won't go CYA when problems happen.

aylons 11y ago
> Engineering is applying scientific principles to solve a problem This is too broad a definition to be useful. Any respected professional will - or at leas try - to do this - be it a medical problem, a law problem, a social problem. What defines the engineer apart is that we try to solve the problems by designing and creating stuff.
nickpsecurity 11y ago
There you have it: developers rarely apply scientific principles to development. The native people would've switched to Ada or Modula-3 long ago if they did. Cleanroom and formal code reviews would've had more takeup after empirical studies showed they worked. Models for safe concurrency from Hansen, Ada, Eiffel, etc would've been widely deployed. Frameworks for web app issues like from OWASP would've eliminated those issues. And so on. Instead, both hobbyist and professional developers seem to systematically ignore every proven thing in their field outside of libraries, apps, or practices that are mainstreamed. It's driven by fads and a throw it together mindset rather than science and robust composition mindset. Meanwhile, groups like Altran Praxis with their Correct by Construction approach continue to show benefits of engineering software.
- rixed 11y ago
  You make it sound like it's developers fault, while in my experience that's merely the market that does not ask for nor reward spending time on correctness (or security) Maybe we are still too early in the initial gold rush?
  - nickpsecurity 11y ago
    I think it's both but mostly the market. I've written essays condemning the demand side before as ultimately responsible. Yet, remember the users make up most of the demand. They want it faster, more features, cheaper, and so on with very few willing to sacrifice any of that for quality or security. So, companies focusing on the latter mostly withered with remainder in niche. Most deliver users (or shareholders) what they wanted or a knock off of it. The part where I see developers at fault is rejecting options that improve things, for them and users, that they can actually use within this mess. An example might be the web security frameworks for PHP while developing a PHP service. It takes almost no work to use them with many components pre-built. They prevent total disruption of service or record theft from hackers. So, why aren't the developers using them? This problem manifests all over the stack for many preventable issues. Most developers consistently refuse to put in a little extra rigor or effort upfront to prevent problems down the line. Those that do... a little closer to engineers to me... experience rewards then write blog posts or papers encouraging others to do it. They're mostly ignored. This is the problem. Management and users aren't causing this one.
- mattlutze 11y ago
  It may very well be that the software industry needs a more formal structure of Professional Engineers like the rest of the applied sciences / engineering disciplines have. http://www.nspe.org/resources/licensure/what-pe http://www.nspe.org/resources/licensure/what-pe What disciplines in software development truly need the concept of a a big-e Engineer? Which don't? http://theinstitute.ieee.org/ieee-roundup/opinions/ieee-roundup/misconceptions-about-licensing-software-engineers http://theinstitute.ieee.org/ieee-roundup/opinions/ieee-roun... More fundamentally, have the practices and knowledge in software engineering yet reached a point of maturity, that licensing Professional Software Engineers would be ethical? https://en.wikipedia.org/wiki/Software_engineering_professionalism#History https://en.wikipedia.org/wiki/Software_engineering_professio... Until then, it doesn't feel particularly useful to have folks coming up with their own pet definitions and adding confusion to a sufficiently broad, fluid profession.
  - nickpsecurity 11y ago
    It could be too immature to start licenses and such. That's an open topic of discussion. Our field is new and changes rapidly. It wouldn't surprise me if we haven't learned all the key things we should know. Yet, engineering of software is a term that goes way back to Hamilton of Apollo, Dijkstra, Cleanroom, etc. It's clear meaning was that software was built piece by piece, analyzed, integrated, tested and maintained all using methods proven by experiment in Comp Sci and industry. A scientific approach to building software whose methods could be evaluated by their results and consistency. Against this, there were people who threw together Fortran, COBOL, later C, and so on. They had an idea, wrote whatever code seemed to implement it, maybe did some testing, and put that stuff in production. Problems, often predictable, occurred that disrupted service and leaked people's data. Over time, almost trial and error, they re-discovered a subset of prior engineering practice that prevented some problems, continued to ignore others, and developed best practices of their own within silo'd groups. Their work continued to be lower in quality and predictability versus those like Altran that continued engineering tradition. So, I think there's a clear distinction between two approaches to constructing information systems. One strictly leverages proven techniques in careful combination with lots of review, analysis, and testing. One does whatever it feels like with some feedback from others in their camp and optionally some engineering tricks. The disparity in results confirms both that there's a difference and the superiority of engineering rather than developing software. Now, the Etsy CTO might be adding his own stuff in there. This probably isn't warranted as it does cause confusion. I'm sticking with the original definitions centered on problem-solving philosophy and evidence-driven practices.

aylons 11y ago

> Engineering is applying scientific principles to solve a problem This is too broad a definition to be useful. Any respected professional will - or at leas try - to do this - be it a medical problem, a law problem, a social problem. What defines the engineer apart is that we try to solve the problems by designing and creating stuff.

nickpsecurity 11y ago

There you have it: developers rarely apply scientific principles to development. The native people would've switched to Ada or Modula-3 long ago if they did. Cleanroom and formal code reviews would've had more takeup after empirical studies showed they worked. Models for safe concurrency from Hansen, Ada, Eiffel, etc would've been widely deployed. Frameworks for web app issues like from OWASP would've eliminated those issues. And so on. Instead, both hobbyist and professional developers seem to systematically ignore every proven thing in their field outside of libraries, apps, or practices that are mainstreamed. It's driven by fads and a throw it together mindset rather than science and robust composition mindset. Meanwhile, groups like Altran Praxis with their Correct by Construction approach continue to show benefits of engineering software.

rixed 11y ago
You make it sound like it's developers fault, while in my experience that's merely the market that does not ask for nor reward spending time on correctness (or security) Maybe we are still too early in the initial gold rush?
- nickpsecurity 11y ago
  I think it's both but mostly the market. I've written essays condemning the demand side before as ultimately responsible. Yet, remember the users make up most of the demand. They want it faster, more features, cheaper, and so on with very few willing to sacrifice any of that for quality or security. So, companies focusing on the latter mostly withered with remainder in niche. Most deliver users (or shareholders) what they wanted or a knock off of it. The part where I see developers at fault is rejecting options that improve things, for them and users, that they can actually use within this mess. An example might be the web security frameworks for PHP while developing a PHP service. It takes almost no work to use them with many components pre-built. They prevent total disruption of service or record theft from hackers. So, why aren't the developers using them? This problem manifests all over the stack for many preventable issues. Most developers consistently refuse to put in a little extra rigor or effort upfront to prevent problems down the line. Those that do... a little closer to engineers to me... experience rewards then write blog posts or papers encouraging others to do it. They're mostly ignored. This is the problem. Management and users aren't causing this one.
mattlutze 11y ago
It may very well be that the software industry needs a more formal structure of Professional Engineers like the rest of the applied sciences / engineering disciplines have. http://www.nspe.org/resources/licensure/what-pe http://www.nspe.org/resources/licensure/what-pe What disciplines in software development truly need the concept of a a big-e Engineer? Which don't? http://theinstitute.ieee.org/ieee-roundup/opinions/ieee-roundup/misconceptions-about-licensing-software-engineers http://theinstitute.ieee.org/ieee-roundup/opinions/ieee-roun... More fundamentally, have the practices and knowledge in software engineering yet reached a point of maturity, that licensing Professional Software Engineers would be ethical? https://en.wikipedia.org/wiki/Software_engineering_professionalism#History https://en.wikipedia.org/wiki/Software_engineering_professio... Until then, it doesn't feel particularly useful to have folks coming up with their own pet definitions and adding confusion to a sufficiently broad, fluid profession.
- nickpsecurity 11y ago
  It could be too immature to start licenses and such. That's an open topic of discussion. Our field is new and changes rapidly. It wouldn't surprise me if we haven't learned all the key things we should know. Yet, engineering of software is a term that goes way back to Hamilton of Apollo, Dijkstra, Cleanroom, etc. It's clear meaning was that software was built piece by piece, analyzed, integrated, tested and maintained all using methods proven by experiment in Comp Sci and industry. A scientific approach to building software whose methods could be evaluated by their results and consistency. Against this, there were people who threw together Fortran, COBOL, later C, and so on. They had an idea, wrote whatever code seemed to implement it, maybe did some testing, and put that stuff in production. Problems, often predictable, occurred that disrupted service and leaked people's data. Over time, almost trial and error, they re-discovered a subset of prior engineering practice that prevented some problems, continued to ignore others, and developed best practices of their own within silo'd groups. Their work continued to be lower in quality and predictability versus those like Altran that continued engineering tradition. So, I think there's a clear distinction between two approaches to constructing information systems. One strictly leverages proven techniques in careful combination with lots of review, analysis, and testing. One does whatever it feels like with some feedback from others in their camp and optionally some engineering tricks. The disparity in results confirms both that there's a difference and the superiority of engineering rather than developing software. Now, the Etsy CTO might be adding his own stuff in there. This probably isn't warranted as it does cause confusion. I'm sticking with the original definitions centered on problem-solving philosophy and evidence-driven practices.