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 (0)

Write comment

Show/hide comment form