Software
engineering is not an accurate way to describe what software designers and
developers do. We create software in an environment that is constantly changing
to fulfill the expectations of businesspeople who aren't exactly sure what they
want. Does that sound like engineering? As I'll discuss in this article, physical
engineers deal with the universal laws of physics, but software designers and developers
deal with unrelenting change. By using the word engineering to describe our profession, we set ourselves up for static
processes and brittle team structures that tend to discourage change, rather
than folding it into our everyday lives. Once we can shift our mindsets away
from engineering our software, people, and processes, we'll find that our teams
are more responsive, productive and change-ready
than ever before.
As a point of comparison, let's look briefly at physical engineers who are
responsible for designing and building bridges. Similar to software developers,
they look to define a problem (a road needs to cross a river), design a
solution (blueprints), and build the solution (the finished bridge). There is
also significant materials testing that goes on throughout the process.
Building Bridges Versus Building
Software
A bridge
engineer's central concern is less about the aesthetic of the bridge and more
about making sure that the bridge will last and will not collapse. The engineer
must grapple with a set of constraints to ensure that he is successful. The
constraints include certain expectations from the client, but his focal
constraints have largely to do with the science of physics. Where every beam is
placed and the position of every bolt is dictated by physical laws which will
work to strengthen the design or destroy it.
Now let's flip to software developers. We are also employed to solve a
particular problem, which we analyze, design, build, test, and deploy. So far,
this is similar to the role of a bridge engineer. But now we examine the issue
of constraints. Physics isn't a big concern for software designers, because our
end product is intangible, but we do have other constraints. Our constraints
come from the business rules and the information needs of our stakeholders.
These provide the boundaries/scope for our development efforts.
Advertisement
Now let's
compare the two sets of constraints. The bridge engineer works with the laws of
physics. We work with the expectations of stakeholders. The laws of physics are
well-known, well-documented, are non-situational, and do not change. The
expectations of software stakeholders, however, are usually not well-known
(even to the stakeholders), not well-documented, very situational, and
extremely volatile. I've even seen projects that were drastically altered in
midstream based on a magazine article that an executive read on an airplane!
You probably have too. Sometimes the changes seem frivolous and sometimes they
are clearly business necessities, but the volume of change is a certainty with
software development.
This is a major contrast. Software developers have to deal with a lot more
change in the lifecycle of a project than does the engineer with the bridge.
Yes, the engineer will learn more about the problem domain as he proceeds. He
might find out that a particular piece of ground is less firm than he was
expecting and have to change his strategy because of that, but the original
problem and the constraints of physics remain the same.
Please note, I am not saying the job of a bridge engineer is easy. This work is
extremely difficult and requires great intelligence, discipline, and
creativity. Imagine what it's like to have the responsibility for creating a
physical structure that society will depend upon! But my point is that it is
fundamentally different than what we do in software development.
People Are Different, Too
The
difference in the amount of change is only one factor. Think about the
qualities you want to see in a bridge engineer. What does
"professionalism" mean in bridge engineering? It is hard to
categorize any profession, but you could see how engineers really need to be
people who are exacting, precise, and methodical. They will usually be
product-oriented and not people-oriented.
Now what about professionalism in software development? Again, there is
significant contrast. Most of us are far more people-oriented than
product-focused. The best programmers I've seen have not been overwhelmingly
methodical and meticulous. They are more often creative, love change, and can even
be a bit nutty. Certainly the best requirements analysts are not heads-down,
detail-obsessed, engineering-types. They have to understand the often fuzzy
feature requests and deal with the uncertainty and change that comes with the
terrain of business departments and business people. Testers can be somewhat
more methodical, but they also must adapt to the changes inevitable in a
software lifecycle. Rolling with the punches is possibly the most
desirable personal quality of any software person.
But can you imagine driving over a bridge designed by an engineer who admitted
to being "a bit nutty" or wasn't very "detail-oriented?" No
way!
In software, we need teams that combine detail-orientation with very people-oriented
qualities. We constantly need to guard against the very real possibility that we're
actually solving the wrong problem (a non-detail issue) and so we need our
non-detailed people around to tell us that. Engineers seldom build a bridge
across the wrong river, so they don't have this same type of worry.
Encourage Don't Discourage Change
So why
have I spent all this effort to simply avoid using a term that few people even
use anymore? Actually it's not the term itself as much as what the term implies
for our teams. The more we think of ourselves as engineers, the more we will
try to engineer our solutions, our processes, and even our people. The
engineering model was created to build static physical structures and machines.
It was not meant to deal with constant change and flux. All of us approach
solutions differently if we know we are expecting a lot of change. Imagine a
bridge that was meant to change. It might be made of a set of building blocks
that could be taken apart and moved quickly to another river. Actually,
the military is quite good at building temporary bridges. But most bridge
engineering is not about creating something to be changed.
In software development, change must be our constant companion. We need to be
ready to handle changes during the development lifecycle. We need to create
software that can be changed after it goes into production as the business
changes. Newer design and programming paradigms like object- and
component-orientation are what we use to facilitate constant change.
Iterative/incremental lifecycles like the Rational Unified Process (RUP) and many
of the Agile processes are ways for us to cope with changes to requirements and
other factors all the way through the lifecycle. When I say "handling
change" I am not talking about the typical change management. That
model is not about handling change in any meaningful way. It is about change
discouragement. In this article, I am really discussing a way of adapting
to change coming from the business and incorporating it into everyday life, not
finding ways to halt it. A true engineering approach would focus on
change discouragement, as it should.
In
software, if we discourage changes, we can expect failure. Our constraints come
packaged with change. Our constraints are the expectations, needs, wants, and
feelings of people. As Jeanne Baker, Lead Program Manager of the BizTalk team
at Microsoft, has said: "Our product managers don't want the solution they
wanted at the beginning of the project, they want what they want at the
end."[i]
They are usually two different things. We have to match the business peoples'
expectations with our processes. If we engineer our processes too much, we
can't give our business users the solution they want at the end of the
lifecycle.
Don't Choke Creativity
Hopefully,
you can see how the engineering mindset can hurt our processes. But it also
hurts our people. Highly-engineered processes and organizational structures are
not enjoyable places to work. As managers, it may seem that the easiest type of
organization to create and manage is a machine-like structure. Everybody does
their well-defined job. Handoffs are clear and crisp, with no chaos, just
efficiency. But viewing people as cogs in a machine is too limiting. You, as
their manager, effectively cut yourself off from each person's creativity. And you
inhibit the organization's ability to change because of that. Carol Pearson,
former editor of the Inner Edge magazine, said that "Continuous creativity
can help us rise to the challenge of continuous change."[ii]
I would emphasize that creativity is the only
way to create a team that is "change-ready."
All human beings have a need to improve their own lives, including their work.
If we can think of a better way to do something, we instantly want to try it.
But a highly-engineered machine organization can't handle many new ideas. There
is always a fear that if one of the people starts playing around with his
responsibilities, the rest of the machine will seize up from the shock. And
that may be true in an organization where people need to behave as machines.
Having focused on how our people and our processes must not be treated like
machines, it is worth noting that the software we create as an end product is
indeed a machine. The trouble we get into is when we extend that machine
metaphor outside the domain of the actual running software to the rest of our
world, to people and processes. But if we can limit our machine thinking just
to the software itself as coded and executable, we won't have the
over-engineering problem.
I am introducing some ideas here that may help make people's lives better and
make employees and team members happy. I am discussing ways to achieve their
happiness by giving them more control over their own work. I'm not saying that
people's happiness at work can be improved with the usual means, like parties,
rewards, celebrations, bigger offices, recognition, etc. Most of the
time, these mostly superficial happiness generators have no lasting impact on
people's happiness at work.
If you've ever done manual labor of any kind, whether pouring cement or being a
maid at a hotel, you know that the job becomes more enjoyable when you can
experiment with your own improvements, and less enjoyable when you can't.
You Can't Engineer for Change But can't you
just "engineer for change?" No, you really can't. Because in an
engineered machine-model organization, you would have to anticipate every
possible type of change and engineer your team for them all. It is impossible.
A machine can't creativity respond to changes in its environment. It has to be
told what to do.
What you can do is let your team members make improvements to their own work,
giving them a wide berth of responsibility and flexibility over how they do
what they do. It is not "chaos reigns" but just allowing some
creativity to sneak in the door once in a while.
Our processes and our people are better off not being engineered. So
what is our alternative term to "software engineering?" There are so
many possibilities; it's really up to you. To call what we do software development isn't too
far-fetched, and it is a term we already use widely. Other acceptable labels
might be software creation or software synthesis, which help us avoid
the static structure mindset. Finding the best term to replace software
engineering is less urgent than shifting our mindsets away from engineering
software, processes, and people. If we can accomplish that, we'll have come a
long way.
About the Author
Daryl
Kulak is a methodology coach with Perficient,
Inc., a NASDAQ-listed IT consulting firm. Daryl is the co-author of Use
Cases: Requirements in Context (Addison Wesley, 2003) and is co-authoring
the upcoming Agile + Rigor with
Dr. Hong Li, due out in the fall of 2008. Daryl is based in Columbus, Ohio
and works with clients to improve their software development processes and
teams.
[i] Personal communications (with permission) with Jeanne
Baker, Microsoft.
[ii] "Creativity and Human
Fulfillment" by Carole S. Pearson, PhD. Inner
Edge Magazine, Vol 2, No 5, Oct/Nov 1999.
Comments (14)
john: ...
this articles reminds me of some Germans I used to know. They are some anal and uptight about their titles, that they would correct you if you didn't address them as Dr. if they were a PHD. In fact, you could say the same about PHD couldn't you? Why are PHD's doctor's? We all think of Doctors first as the medical type.
I think this is an exercise in a lot of wasted time trying to define, correct, and lecture on labels.
1
July 31, 2008
Daryl Kulak: ...
B.
Interesting comments as well. There is certainly a love affair with the phrase "software engineering" that I need to acknowledge is out there. But I don't think that makes it worthwhile hanging onto.
Your examples of other types of engineering are very valid, and I agree, different types of engineering are closer or further from software development.
Automotive engineering is one I'd like to latch onto. American automotive companies were very involved in trying to "engineer" their workers into boxes, treating them like just another machine. Japanese automotive companies took the opposite approach, they engineered the machines and the end product but did NOT engineer their people and processes. The results were that Toyota, Honda and the others had a dramatic advantage over the heavily people/process engineered Americans for many years and still do, Americans can't seem to catch up.
This article does not say that we don't engineer our end product. We do engineer software. But by using this term, we often end up applying our engineering principles wrongly to people and process, and as a result we put ourselves in the role of Ford and GM when we should be emulating Toyota and Honda.
I think our successes and failures in software development show that, as an industry, we are probably weaker than Japanese and American automakers in most respects. But by keeping our people/process engineering mindset, we can guarantee we'll stay at the back of the pack.
2
December 05, 2007
B. Geahwie: ...
I don't understand why Daryl Kulak is enclosing Engineering in a little 2-inch by 2-inch metal box by making specific reference, but not limiting it, to building a bridge. There are many other engineering disciplines that are more like building software. The fact that one discipline is more venerable to frequent change doesn’t disqualify it as being engineering. Take for example Civil, Automobile and Electronic engineering.
Civil Engineering: Bridges, roads, canals, dams and buildings are basically built in the same way as they were twenty years ago with little or no change.
Automobile Engineering: Motor vehicles have gone through some considerable change over the past twenty years based on people-factor. There are even hybrid vehicles today to minimize the increasing demand for petroleum. People’s demand for more comfort and security has lead to better interior and more airbags than earlier vehicles.
Electronics/Electrical engineering: Think of how electrical and electronics devices have evolved in recent year. The rate of evolution of these devices is such that new devices are released nearly every month. The computer - processor, memory, motherboard, graphic card – is a typical example. These new releases are strictly people-demand-driven (more speed, space, picture quality) and nothing else. Does this make Electronics/Electrical engineering less of an engineering discipline than Automobile Engineering and Civil Engineering an even lesser engineering discipline? No!!
Software Engineering is one discipline that lends its development to very frequent change. For the fact that changes can be applied during its development stage doesn’t disqualify it as being engineering. The frequency of change during the building of a bridge is only far less and minor than that of software development.
Until I am convinced that Software development does not involve acquiring and applying scientific and technical knowledge to the design, analysis, and/or construction of works for practical purposes, I will stick to the term Software Engineering.
B. Geahwie WPI
3
November 27, 2007
Hong: ...
I'm a co-author of Daryl's. I have to say that the concept of "burying XX engineering" may be a little dramatic. But it serves for the purpose of a wake up call. One of the central messages of the article is whether we want to see these engineering guidelines or methodologies burying people including engineers who make the engineering projects work.
We may quote from many textbooks, standards, or even best practices to demonstrate engineering represents creativity and disciplines, but few of them have explicitly and sufficiently emphasized the key roles of people. Are we dealing with a business that applies branches of technologies to ultimately reduce the roles of people to zeroes?
When we quote the ancient engineering projects such as Great Wall or Egyptian pyramids, we may be overwhelmed by these great wonders if we ignore the social costs of them at the time when they were built. But how many of us do want to become those slavery engineers for the projects that served solely for the glories of emperors?
If we see a typical mindset in today’s industry is that engineers should be engineered in the same way as those engineering projects these engineers have to work with, we will tell the fundamental guidelines have probably not changed much since Great Wall and Pyramids.
I don’t think mechanical procedures and technical standards will help us turn around in our practice, but at best serve as bandages to cover up those deep wounds…
4
November 18, 2007
Daryl Kulak: ...
Oh well. I guess html doesn't show up at all. You'll just have to copy-and-paste the link to the Checkland article. Sorry for the unnecessary multi-posts here.
Hmm, looks like the link I provided wasn't clickable. Let me try it again:
What Checkland is saying with his methodology is that systems engineering that tries to "engineer" situations that are largely political, social and human-oriented doesn't work. We need another process that can deal with the "softer" side of systems. He feels that Soft Systems Methodology (SSM) fits that bill.
I've heard it said many times that no software project has ever failed due to technical reasons, only political reasons. Would you say the same about bridges?
It seems that maybe half of the comments here can be summarized by the statement "But bridge engineers have to deal with politics and people too, and software engineers have to deal with physics."
While this is true, I feel it is an oversimplification. Which ones have to deal with *more* people issues? I think software, with its focus on satisfying businesspeople's needs and its inherent intangibility, has much more reliance on people issues than physics. I would say that physics play an almost irrelevant role in software development. I personally have never seen a software project (or even module) fail because of physics.
So if software projects really do fail almost always because of political reasons, shouldn't we search for an alternative to systems engineering / software engineering that caters to those aspects, rather than trying to wedge the square peg of engineering into the round hole of politics?
Thanks again for all the comments.
6
November 18, 2007
Daryl Kulak: ...
Well, it looks as if I have struck a nerve. I was hoping to generate conversation from this article and I'm glad that it has happened.
Rather than responding to each individual criticism, I'd like to refer my commenters (and others) to another author who has also drawn the ire of the software engineers. His name is Peter Checkland, creator of "Soft Systems Methodology." He felt quite strongly that the engineering mindset lacked the tools he needed to solve business problems, and created the Soft Systems Methodology as a replacement for it.
One of his most popular books (in the systems thinking area) is called "Systems Thinking, Systems Practice." There is also a pretty good article on the Web done by some University of Calgary students here:
Thanks everybody for the spirited discussion. I'm interested to hear from those who read Checkland's methodology and report back on impressions about that.
7
November 18, 2007
Adail Muniz Retamal: ...
I disagree with both the title and body of the article. The title is sensationalist, at best.
Engineering is a mindset which is very much creative and agile, yet with a high degree of responsibility and accountability, while applying the scientific knowledge to practical situations in a systemic/holistic way.
Thinking that software is not bound to Physical Laws is ignoring the basic Electronic and Boolean Laws governing the hardware where the software runs. It's possible to code a very "interesting" algorithm that will simply not work in a given environment.
Nice try, but Software Engineering still rules! :)
8
November 17, 2007
Victoria K: ...
So, sometimes engineering can be creative and sometimes it can be boring. And yes, different people work differently. And some of them will keep putting blocks one on another in a methodical manner and will create a Great Wall of China that people will admire for centuries, or a sturdy house that will be reliable and serve the purpose for a few generations. Others will create a spaceship or a beautiful cathedral that nobody had ever imagined before. And it’s all going to be based on business requirements: “I want a nice place to live in”, “I want to reach stars”, “I want something beautiful built in the city, for which people will know and remember me”. And although, in a lot of cases they will be built based on vague and changing requirements, they all will require discipline, rigid processes, strict definitions, or they simply wouldn’t work.
Isn’t it the same as a software development though? Yes, it takes creativity to imagine the solution, which is more elegant or will provide the means to “reach the stars”, but don’t we need to put brick after brick and know where and when to put those bricks, and don’t we require discipline, rigid processes, and strict definitions, or those creative solutions will simply never work?
Do electrical, construction, automotive, or software engineers require changes in the culture and processes to bring out the creativity into the process? Yes. But, isn’t it taken care of by evolution process? Have you noticed that the ratio of micro- to macro-managers in IT has changed from 1:2 to at least 1:10 in the last decade? But isn’t it just natural selection process that allows to gradually raise the level of creativity by increasing the level of automation of redundant processes?
As for me, if the engineering is defined by the ECPD statement from Wikipedia, and the engineer is defined as “one, who practices engineering”, I feel pretty comfortable being called a Software Engineer.
Ok… now that I’m done with my “I’d argue with a streetlight pole if given a chance” mode, I must admit... so long as it’s not called “intelligent design”, I’m fine with it :)
Sincerely, Victoria
9
November 15, 2007
Victoria K: ...
WIKIPEDIA: Engineering is the discipline of acquiring and applying scientific and technical knowledge to the design, analysis, and/or construction of works for practical purposes. The American Engineers' Council for Professional Development, also known as ECPD,[1] (later ABET [2]) defines Engineering as: "The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property."
Did you notice how the first adjective in the ECPD’s definition of engineering is “creative”? I think the term "engineering" was a little simplified in Daryl’s article. Nobody knew what the spaceship would need to look like when they started designing it. Engineers (I must add, very talented engineers!) imagined what might work first based on pretty vague and agile requirements (“it must make carry a human being into the space and come back”). Despite vague and constantly changing requirements, they actually built it, and it worked!
And then, we have the Great Wall of China and Egyptian pyramids, and Saint Basil’s Cathedral, etc… If that’s not an example of creative engineering with constantly changing requirements, what is?
Ok… let’s go into the less romantic and more pragmatic areas of life. Take a car, for example… the high-level business requirements for building a car would be something like “it needs to drive smoothly, stop promptly, run quietly, have a pleasing appearance, and be comfortable”. How much creativity, but also discipline and rigid process, is required to create hundreds of different models that run just a little smoother or rougher, a little quieter or louder, depending on oh! so vague and ever-changing automotive market requirements?
We have houses that can be delivered to the location and assembled based on instructions. Yes, they may have different colors paint, different materials, and it makes them look different. I've been in the house like that a year or so ago. That house was almost 3,000 sq feet and cost over half a million. Yeah, yeah, yeah… it was located in CT, but still it was ASSEMBLED! If I wasn’t told that, I would never guess. How creative the engineering process of building/assembling the house itself was? Not very… it was assembled, but the results were amazing!
Didn’t it sound pretty much like using VB or PeopleSoft or Oracle to build a simple application? Well, if you thought about doing that 20 years ago (think about it… JUST 20 years ago!), we didn’t always believe or could even imagine that those “simple” applications would ever work? And now, we call the process of building those applications boring and non-creative.
My comment is too long... see further :)
10
November 15, 2007
Lee: ...
I would suggest that some areas of engineering deal with similar sorts of change to what we see building computer systems.
Any product related engineering has the problem we have with requirements change. Thats why the Boeing 777 is late, as I read it. The requirements changed in mid-project. Automotive work is similar. If everyone starts buying SUVs that look like sports shoes and have more cup holders, then all the automotive engineers get change requests.
Think about the engineering that goes into a deep-space probe. They literally don't know what it is going to find but they work with the best information they have and come up with something that can be adjusted on the fly, if need be.
I suspect the bridge guys have the same problems when the Republicans get voted in and they don't like the bridge designs okayed by the Democrats. (or vice versa) It's even worse in countries where the government changes by violent overthrow or disintegration.
Finally, all types of engineering have breakthroughs and research to deal with. The new airplanes have a lot of carbon-fiber in them to reduce weight. (Ignore that the price of oil effects the need for reduced weight right in the middle of a project.) They didn't always know how to create that quantity of carbon-fiber, at a reasonable cost, with proper quality control. So, as they are designing the plane, they are dealing with the unfolding of knowledge about this new material.
Electronics engineering deals with the same thing. New electronic devices and faster embedded processors and such pop up every month. Those engineers make the trade-offs required to either include or ignore the new technologies.
11
November 15, 2007
Paul Sirianni: ...
I have to disagree on Daryl's definition of "Engineering". Engineering is the application of science and mathematics to solve "real world" problems. Using Software to solve problems is applying Computer Science to, in your terms, fulfill the expectations of businesspeople ( i.e. solve "real world" problems). The "problem" with software today is that scientists (computer scientists) are creating it rather than Software Engineers. There needs to be more engineering in software development. That doesn't have to mean the rigid processes and structures Daryl is talking about. There are plenty of examples of Agile engineering in other engineering disciplines and industries ( e.g. automotive industry).
Thanks,
Paul M. Sirianni Senior Software Engineer
12
November 15, 2007
Daryl Kulak: ...
Joe,
Great comment.
What I try to watch for is any aspect of treating people like machines, and the "engineered" guidelines can sometimes get into a situation where we're trying to "put people in their place" and getting them to act like a cog-in-the-wheel. Often, it is not the fact that guidelines exist that's the problem, it is the way the guidelines are used. If the guidelines are there and we say "use the guidelines but also use your head" it is okay. When we say "these guidelines have been engineered by smarter people than you so just follow them" we get into trouble.
But I can see what you're saying that we need some of those engineering aspects, and that my article (especially at this length) oversimplifies that point.
Again, I appreciate your insightful comment.
13
November 15, 2007
Joe Farah: ...
Hi Daryl, Interesting perspective, but I think it differs from mine. Engineering is about developing guidelines that can be followed to enhance the quality/success of the products. There are guidelines for bridges, for different joints and load-bearing members. Similarly there needs to be guidelines for software development. These are systems which are often more critical than bridges, more often, not so.
Yes software is intended to facilitate change, so that makes the software engineering task all the more difficult. But we have software engineering guidelines that dramatically make a difference in our software products. Simple guidelines mostly, but many of them. For example:
1. For local identifiers assume a context when selecting a name (e.g. count). For global identifiers, assume no context (e.g. RepositoryTableCount).
2. Use white space effectively. Minimize its use to keep more information on a page, but use it to effectively separate blocks of code.
3. Single entry, single exit for all functions and procedures. This way when looking at a block of code, you don't have to inspect the entire procedure to understand what the conditions are that lead you to it. The indentation (and conditions thereof) are sufficient.
4. One branch per product release (ie. product branch). Use other mechanisms to control promotion, collect files of a change, etc. This way, there's no room for error.
5. Use "while" conditions at the beginning of a loop, not "until" conditions at the end of a loop. This allows easier readability and maintenance.
6. Always use 0-based looping and indexing. for (i=0; i < count-1; i++) This way all loops have the same boundary behaviors leading to way fewer errors.
7. All code is peer-reviewed, along with a demo if applicable. This is where most errors are uncovered.
OK... this is just an example of the dozens of software engineering guideline we use. Software is way more complex than any other discipline of "engineering" (ie. building things). The tools used to be more complex, are are better understood these days. But the product is way more complex. We need more and more software ENGINEERING guidelines.
Our software engineering guidelines typically allow our software products to be an order of magnitude better with an order of magnitude fewer lines/less complexity.
Dealing with change is something we've effectively engineered into our solutions. We did not take the non-engineering approach that says: "it's software so it can be changed". We built the software both so that the software is easy to change and so that the customer has flexibility in using the software so that we don't have to change it as much. This is the result of engineering.
Still, from one perspective I whole-heartedly agree with you. Software designers and programmers most frequently don't do a lot of engineering. They copy/paste/adapt, they find one way to do it rather than derriving the "best" or "appropriate" way. And tool makers cater to this philosophy. They make tools that allow object-oriented programming, or extreme programming, or traditional procedural programming, or neural network (adaptive learning) programming. A solution will involve a mix of these, not a single up-front choice of which toolset to use.
So we're lost... we're not doing a good job of software engineering. More than that, we're not teaching effectively what software engineering is all about and why and how it is so beneficial. That's what the other disciplines of engineering do with their methods and procedures. And when this is not done in software, the term software engineering should not be applied.
From a creative perspective, electrical engineering (specifically, electronics engineering) has the same creative properties as software, though slightly less complex, and definitely more difficult to change. Yet they manage to put engineering guidelines in place, which have to change as technology evolves at a dizzying pace. They do because the cost of fixing is too high - not just a downloaded patch. Cost should not let software developers off the hook. In fact, because of the higher level of complexity, and lack of engineering guidelines, product-wide, software costs more than hardware to change.
Anyway, that's another perspective... let's not drop the term, let's do the engineering.
Articles 
Software
engineering is not an accurate way to describe what software designers and
developers do. We create software in an environment that is constantly changing
to fulfill the expectations of businesspeople who aren't exactly sure what they
want. Does that sound like engineering? As I'll discuss in this article, physical
engineers deal with the universal laws of physics, but software designers and developers
deal with unrelenting change. By using the word engineering to describe our profession, we set ourselves up for static
processes and brittle team structures that tend to discourage change, rather
than folding it into our everyday lives. Once we can shift our mindsets away
from engineering our software, people, and processes, we'll find that our teams
are more responsive, productive and change-ready
than ever before.
