As a point of comparison, let's look briefly at physical engineers who areresponsible for designing and building bridges. Similar to software developers,they look to define a problem (a road needs to cross a river), design asolution (blueprints), and build the solution (the finished bridge). There isalso significant materials testing that goes on throughout the process.

Building Bridges Versus BuildingSoftware

A bridgeengineer's central concern is less about the aesthetic of the bridge and moreabout making sure that the bridge will last and will not collapse. The engineermust grapple with a set of constraints to ensure that he is successful. Theconstraints include certain expectations from the client, but his focalconstraints have largely to do with the science of physics. Where every beam isplaced and the position of every bolt is dictated by physical laws which willwork to strengthen the design or destroy it.

Now let's flip to software developers. We are also employed to solve aparticular 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 issueof constraints. Physics isn't a big concern for software designers, because ourend product is intangible, but we do have other constraints. Our constraintscome 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'scompare the two sets of constraints. The bridge engineer works with the laws ofphysics. We work with the expectations of stakeholders. The laws of physics arewell-known, well-documented, are non-situational, and do not change. Theexpectations of software stakeholders, however, are usually not well-known(even to the stakeholders), not well-documented, very situational, andextremely volatile. I've even seen projects that were drastically altered inmidstream based on a magazine article that an executive read on an airplane!You probably have too. Sometimes the changes seem frivolous and sometimes theyare clearly business necessities, but the volume of change is a certainty withsoftware development.

This is a major contrast. Software developers have to deal with a lot morechange 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. Hemight find out that a particular piece of ground is less firm than he wasexpecting and have to change his strategy because of that, but the originalproblem and the constraints of physics remain the same.

Please note, I am not saying the job of a bridge engineer is easy. This work isextremely difficult and requires great intelligence, discipline, andcreativity. Imagine what it's like to have the responsibility for creating aphysical structure that society will depend upon! But my point is that it isfundamentally different than what we do in software development.

 

People Are Different, Too

 

Thedifference in the amount of change is only one factor. Think about thequalities you want to see in a bridge engineer. What does"professionalism" mean in bridge engineering? It is hard tocategorize any profession, but you could see how engineers really need to bepeople who are exacting, precise, and methodical. They will usually beproduct-oriented and not people-oriented.

Now what about professionalism in software development? Again, there issignificant contrast. Most of us are far more people-oriented thanproduct-focused. The best programmers I've seen have not been overwhelminglymethodical and meticulous. They are more often creative, love change, and can evenbe a bit nutty. Certainly the best requirements analysts are not heads-down,detail-obsessed, engineering-types. They have to understand the often fuzzyfeature requests and deal with the uncertainty and change that comes with theterrain of business departments and business people. Testers can be somewhatmore methodical, but they also must adapt to the changes inevitable in asoftware lifecycle. Rolling with the punches is possibly the mostdesirable personal quality of any software person.

But can you imagine driving over a bridge designed by an engineer who admittedto being "a bit nutty" or wasn't very "detail-oriented?" Noway!

In software, we need teams that combine detail-orientation with very people-orientedqualities. We constantly need to guard against the very real possibility that we'reactually solving the wrong problem (a non-detail issue) and so we need ournon-detailed people around to tell us that. Engineers seldom build a bridgeacross the wrong river, so they don't have this same type of worry.

Encourage Don't Discourage Change

 

So whyhave I spent all this effort to simply avoid using a term that few people evenuse anymore? Actually it's not the term itself as much as what the term impliesfor our teams. The more we think of ourselves as engineers, the more we willtry to engineer our solutions, our processes, and even our people. Theengineering model was created to build static physical structures and machines.It was not meant to deal with constant change and flux. All of us approachsolutions differently if we know we are expecting a lot of change. Imagine abridge that was meant to change. It might be made of a set of building blocksthat could be taken apart and moved quickly to another river. Actually,the military is quite good at building temporary bridges. But most bridgeengineering is not about creating something to be changed.

In software development, change must be our constant companion. We need to beready to handle changes during the development lifecycle. We need to createsoftware that can be changed after it goes into production as the businesschanges. Newer design and programming paradigms like object- andcomponent-orientation are what we use to facilitate constant change.Iterative/incremental lifecycles like the Rational Unified Process (RUP) and manyof the Agile processes are ways for us to cope with changes to requirements andother factors all the way through the lifecycle. When I say "handlingchange" I am not talking about the typical change management. Thatmodel is not about handling change in any meaningful way. It is about changediscouragement. In this article, I am really discussing a way of adaptingto change coming from the business and incorporating it into everyday life, notfinding ways to halt it. A true engineering approach would focus onchange discouragement, as it should.

Insoftware, if we discourage changes, we can expect failure. Our constraints comepackaged with change. Our constraints are the expectations, needs, wants, andfeelings of people. As Jeanne Baker, Lead Program Manager of the BizTalk teamat Microsoft, has said: "Our product managers don't want the solution theywanted at the beginning of the project, they want what they want at theend."[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, wecan't give our business users the solution they want at the end of thelifecycle.

 

Don't Choke Creativity

 

Hopefully,you can see how the engineering mindset can hurt our processes. But it alsohurts our people. Highly-engineered processes and organizational structures arenot enjoyable places to work. As managers, it may seem that the easiest type oforganization to create and manage is a machine-like structure. Everybody doestheir well-defined job. Handoffs are clear and crisp, with no chaos, justefficiency. But viewing people as cogs in a machine is too limiting. You, astheir manager, effectively cut yourself off from each person's creativity. And youinhibit the organization's ability to change because of that. Carol Pearson,former editor of the Inner Edge magazine, said that "Continuous creativitycan help us rise to the challenge of continuous change."[ii]I would emphasize that creativity is the onlyway 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. Thereis always a fear that if one of the people starts playing around with hisresponsibilities, the rest of the machine will seize up from the shock. Andthat 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 likemachines, it is worth noting that the software we create as an end product isindeed a machine. The trouble we get into is when we extend that machinemetaphor outside the domain of the actual running software to the rest of ourworld, to people and processes. But if we can limit our machine thinking justto the software itself as coded and executable, we won't have theover-engineering problem.

I am introducing some ideas here that may help make people's lives better andmake employees and team members happy. I am discussing ways to achieve theirhappiness by giving them more control over their own work. I'm not saying thatpeople's happiness at work can be improved with the usual means, like parties,rewards, celebrations, bigger offices, recognition, etc. Most of thetime, these mostly superficial happiness generators have no lasting impact onpeople's happiness at work.

If you've ever done manual labor of any kind, whether pouring cement or being amaid at a hotel, you know that the job becomes more enjoyable when you canexperiment with your own improvements, and less enjoyable when you can't.

 

You Can't Engineer for Change

 

But can't youjust "engineer for change?" No, you really can't. Because in anengineered machine-model organization, you would have to anticipate everypossible 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 betold 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 dowhat they do. It is not "chaos reigns" but just allowing somecreativity to sneak in the door once in a while.

Our processes and our people are better off not being engineered. Sowhat is our alternative term to "software engineering?" There are somany possibilities; it's really up to you. To call what we do software development isn't toofar-fetched, and it is a term we already use widely. Other acceptable labelsmight be software creation or software synthesis, which help us avoidthe static structure mindset. Finding the best term to replace softwareengineering is less urgent than shifting our mindsets away from engineeringsoftware, processes, and people. If we can accomplish that, we'll have come along way.

---

[i] Personal communications (with permission) with JeanneBaker, Microsoft.

[ii] "Creativity and HumanFulfillment" by Carole S. Pearson, PhD. InnerEdge Magazine, Vol 2, No 5, Oct/Nov 1999.