Let's Bury the Term Software Engineering

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