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.
{sidebar id=1}
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 
Write comment
|