Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Can software development be considered engineering? If no, what are the things that it lacks in order to be qualified as an engineering discipline? Related to this is this question on Stack Overflow about the difference between a programmer and a software engineer.
There is the Software Engineering Institute at Carnigie Mellon University that prescribes and maintains the CMMI standards. Is this something that will turn development into engineering?
Is software development engineering? If no, what are the things that it lacks in order to be qualified thus?
Yes, software engineering is an engineering discipline.
Wikipedia defines engineering as "the application of mathematics, as well as scientific, economic, social, and practical knowledge in order to invent, innovate, design, build, maintain, research, and improve structures, machines, tools, systems, components, materials, processes, solutions, and organizations." The result of software engineering is a software system that can improve the lives of people, and it can involve some combination of scientific, mathematical, economic, social, or practical knowledge.
In terms of how it's viewed, academically and professionally, it varies. Software engineering programs can be accredited by ABET as engineering programs. Software engineers can be members of the IEEE. Some companies consider software engineering to be an engineering discipline, while others don't - it's a toss up, really.
The best book on this subject is Steve McConnell's Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers. It looks at software engineering as a profession, evolution from a craft to a profession, the science of software development, the difference between software engineering and software engineering (applying engineering practices to software versus engineers who happen to build software, with a case study that includes my alma mater), certification and licensing, and ethics.
Glenn Vanderburg has a series of talks called "Real Software Engineering" that has has given between 2010 and 2015 at a number of conferences, along with two related talks, "Craft, Engineering, and the Essence of Programming" (given in 2011 as a keynote at RailsConf) and "Craft and Software Engineering" (given in 2011 at QCon London). I think these talks are a pretty comprehensive argument for why software engineering is an engineering discipline.
One argument, which Vanderburg brings up briefly in his talks, is the one made by Jack W. Reeves in 1992 (and revisited again in 2005) on what software design is and how code is the output of software engineering design activities (this is also discussed on the C2 wiki). Once you get away from older schools of thought where specification and modeling is software design and into code being software design, some of the relationships between software engineering and other engineering disciplines become more readily apparent. Some differences and the reasons for those differences become even more apparent after you see that economics of software development are vastly different than many other disciplines - construction is cheap (almost free, in many cases), while design is the expensive portion.
Is that [CMMI] something that will turn development into engineering?
No. CMMI is a process improvement framework that provides guidance to organizations on what kinds of activities are useful when building software. Engineering disciplines typically have an engineering process. Having such a process is important for the successful completion of high quality projects. That said, the CMMI (or any other process framework or methodology) is just a single tool - using it won't make you magically advance from a developer to an engineer. However, not following some kind of process is, in my opinion, a sign of a project that is not an engineering project.
Also, what is your opinion on the software engineering courses/certificates?
It's only as much value as other people put into it. There are useful courses and there are useless courses. There are valuable certificates, and certificates that aren't worth the paper they are printed on. There are a lot of factors, from who is endorsing or accrediting the course or who is issuing the certificate to your current industry of employment to your current job and where you want to go.
Coming from a typical engineering background, but making a career in software development, I see large similarities between both worlds. Apart maybe from the exact definition of engineering, I see in practice that developing software is not that different from developing a physical product. At least I think it should not be very different.
Whether you design an aircraft or a software application, for both you need to:
I read somewhere in an other answer that designing software is different because you do not design everything before you start programming. Well actually to a lesser extent that is also the case when you design a physical product. Designing and prototyping and testing is an iterative process.
Also when software projects grow in size it gets more important to define clear subsystems, components and interfaces which is also similar to designing complex products such as an aircraft.
That is why I consider developing software to be engineering.
I would argue that there is indeed such a thing as software engineering.
Engineering involves the systematic application of scientific knowledge to the solution of problems. The complexity of problems that are tackled today are not that different from those tackled by an electric engineer in creating a circuit or a chemical engineer in devising a manufacturing process or a mechanical engineer in the creation of a device.
The fact that there is also a hands-on approach of applying existing plans (development in this case) is simply similar to the fact that in other fields somebody else executes those plans (e.g., the construction worker).
It is true that most developers also carry software engineering tasks, and that our education is often not in programming but rather in software engineering. So we get our hands dirty whereas a civil engineer would not.
However, the ability to apply a programming language and program does not turn one into an engineer: I have met my share of developers who lack a true understanding of the complexities and issues outside their current piece of code.
As for your question regarding CMU: Application of a standard or practice (e.g., CMMI) does not automatically turn a person's work into engineering. However, the fact that there are organiztions which carry out scientific research to provide new practices is again a sign that there is such a thing as engineering.
No, it's not engineering. We're not that scientific and we don't have to pass any of those state engineering tests. In fact, it's illegal to call yourself a software "engineer" in some places due to that lack of testing.
IMHO the term 'software engineering' was coined to try to better describe the range of things a developer does, rather than just being a 'programmer' (which has overtones of some mechanistic process with little thought or creativity).
Personally I prefer the emerging analogy of a developer as a 'craftsman', championed by the pragmatic programmers, among others.
Historically, people have tried to analogise software creation with manufacturing. I think Jack Reeves made a pretty good argument to discredit this idea in his article What Is Software Design.
From Wiki:
Engineering :
Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.
Software Development
Software development is the set of activities that results in software products. Software development may include research, new development, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.[1]
Especially the first phase in the software development process may involve many departments, including marketing, engineering, research and development and general management.
So they are pretty similar and can also mean the same thing.
From Dictionary.com: en·gi·neer·ing /ˌɛndʒəˈnɪərɪŋ/
–noun 1. the art or science of making practical application of the knowledge of pure sciences, as physics or chemistry, as in the construction of engines, bridges, buildings, mines, ships, and chemical plants.
I would say that creating software is the practical application of math and computer science, and potentially of any other number of pure sciences depending on the application.
[EDIT] FWIW, I don't call myself a software engineer, but a software developer so I don't have a personal stake in this.
In my view a Software Engineer and Software Developer are two different things.
I see a software engineer as one who does planning, such as what life cycle will the development take, doing requirements/specifications, etc... Basically, a software engineer deals with lots of documentation. This can be accomplished by a software developer and/or project manager.
A software developer would be more closely related to a programmer but with more skills in other areas like database management, etc..
One interesting thing to bring up is Architecture. Someone who is also involved in figuring out what hardware/software will be needed for the life cycle of the project.
I'm going to go with "No" here. My brother is a mechanical engineer, and he describes engineering as "The Art of Being Cheap":
"Engineers are more concerned with getting things done as fast as possible, at the lowest cost possible, with the fewest materials possible."
In reaction, I've come to describe software development (not software engineering - they really are fundamentally two distinct fields) as "The Art of Being Efficient":
"Developers are more concerned with getting things done as fast as possible, at the lowest cost possible, with the least amount of repetition possible."
The difference is in the last part of those sentences.
Is software development engineering?
No. Being an engineer means your project follows a cause-and-effect timeline - you follow the building codes, therefore your building doesn't fall down (or at least you can't be blamed if it does). Writing software, you can follow all the guidelines going (and there's so many different ones to choose from!) and it still might hang/crash/give wrong answers (unless you're involved in the remarkably small field of writing provable programs in side-effectless functional languages).
I see an engineer (mechanical, structural, software) as someone who designs the product beforhand based on the understood needs and an understanding of what and how to apply the materials to accomodate that need.
For example, you may often see a structural engineer looking up different strengths of steel and applying rules of physics to calculate materials required and how they should be implemented. Structural engineering is a prime example because you always end up with a blueprint (specification) of what you're going to build before you build. That doesn't always happen with software.
To me the difference of a software engineer and a programmer is that the engineer is capable of building the specification for what will be produced before writing any code, where a programmer either just writes the code based off someone elses specifications, or is one of those wild west programmers who writes code without specifications. As well, the engineer has his degree.
I liken the difference between a construction worker and a structural engineer to the difference between a programmer and a software engineer.
To clarify, I only have a college diploma, so can't call myself an engineer.
I wouldn't consider the term "engineering" as the most appropriate to describe software development, for 2 main reasons :
It conveys a lot of old ideas, concepts and so-called "golden rules" originating in traditional engineering disciplines such as industrial, civil, naval, or mechanical engineering. I'm talking about rules in labour division, production processes, quality standards... These most often only marginally apply to software.
It fails to describe in a satisfying way what programming has more than other disciplines (and I believe it has a lot more and a lot different), and what new challenges developers have to face on a day to day basis compared to their counterparts in traditional enineering domains. Software's virtual and immaterial nature plays a huge role in that.
Software development has long been seen as "just another engineering discipline". Considering the failure rates of software projects we have known ever since they were measured, it's high time we recognized develoment as an entirely new animal, code as a really special material and application lifecycle as a totally different kind of production cycle, and stop desperately trying to apply old recipes to them.
Yes, one should be able to apply standards and principles to arrive at a decent product. What makes it difficult is the mindset of the client (it's just code - it shouldn't cost that much to change), the extreme difficulty in codifying what the product should do into machine code (spoken/written language to code) and quantifying "quality". Your definition of quality isn't mine.
It's also repeatability. Take a set of requirements and give it to two teams. When you can get the same thing out (without the teams talking to one another) you're pretty close to engineering.
Other areas of engineering also have penalties and a rigid review and sign off. Accountability.
No. Software Engineering is not engineering. In my opinion, the difference is in the amount of creativity involved. In Civil Engineering, for instance, there can be very little or no creativity. This is a good thing.
To construct a bridge, you have a set of specifications (I need to get this number of cars from this side of the river to the other side).
From this, I can deduce:
Then, I must get the design approved and checked by a third party (another company) to ensure that I've done my calculations correctly.
Then, when the bridge is actually constructed, the work will be done by qualified people in a standard way. They will be doing work that they have done hundreds, maybe thousands of times before.
Don't get me wrong, every civil engineering project is different, but it seems every time I develop a new application/website, things get done differently.
Yes I'd guess that development is a subset of engineering:
Code Complete defines "construction" as being synonymous with coding and debugging (and commenting), also with detailed design before-hand and with unit- and integration-testing afterwards. Chapter 1, Welcome to Software Construction (PDF) starts by listing many topics in the overall Software Development Lifecycle (including Problem Definition, Software Architecture, Corrective Maintenance, etc.), and then says,
As the figure indicates, construction is mostly coding and debugging but also involves detailed design, construction planning, unit testing, integration, integration testing, and other activities. If this were a book about all aspects of software development, it would feature nicely balanced discussions of all activities in the development process. Because this is a handbook of construction techniques, however, it places a lopsided emphasis on construction and only touches on related topics. If this book were a dog, it would nuzzle up to construction, wag its tail at design and testing, and bark at the other development activities.
Software development is engineering.
A few arguments made by others for why software engineering does not meet the standard of engineer:
Some say engineers are in the business of designing "things" for the public good - are ICBMs, Tanks, etc in the public good? Some would say yes (a good offence is a good defense) others would say no. However, I don't think anyone would disagree that the guy who designs the next generation tank targeting system is an engineer. Public good can be subjective. At any rate plenty of software is in the public good so the point is moot either way.
Others say engineers design they don't build. I have seen several "mechanical engineers don't weld" type comments. I would argue that mechanical engineers produce blueprints - detailed designs that something else implements. If a mechanical engineer produces a blueprint and feeds that to a CNC machine does that make them no longer a mechanical engineer - because a machine did the implementation instead of a person? I would argue that source code is a detailed blueprint that is fed to a machine that does the implementation and I fail to see how that is any different than a MechE feeding code to a CNC machine. And we now have 3d printers, does that signify the end of mechanical engineers? Are they now mechanical developers?
Licensure is the other topic that I see come up. Currently only a few jurisdictions license software engineers. There is (so far) no US wide licensing of software engineers (I think only Texas does so). Some have used this as a reason to state that software engineering should not be called engineering. The PE for software engineers is coming. But on a more philosophical level just because some state legislators choose (or not) to call software development engineering has no effect on reality.
