3 ms·

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 disci

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.

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.