Is Software Engineeringa Discipline

The best software professionals don't think or act like engineers.

So what do I mean by that? Software engineering, more than any other engineering discipline that I can think of, must deal with the human element, and this is not limited to just the end product or results of our work. The human factor is huge in all aspects of what we do, beginning with the initial concept, all the way to the final roll-out. We're talking chaos here. Engineers tend to be control freaks (not me of course ;-). We simply cannot control all of the factors that influence the outcome of our work. So here is where the real need for creativity comes into the picture. Figuring out how to forge great results in the midst of chaos. Oh and by the way, it is typically not us, the engineers, who get make the call on what whether we hit the mark!

So if you buy my line of thinking, perhaps we should cast off the label of software engineers in favor of something that more accurately reflects what we do (or at least attempt to do). Any nominations? Is it possible that by putting ourselves in the "engineer mold" we are imposing limitations on how we approach problem solving, or in subtle ways, influencing how think?

Don't get me wrong here, I am in no way suggesting that we compromise professionalism. If anything, we must elevate ourselves in this area. We have all heard or participated in the debates about whether or not software engineers are "real engineers". I for one am not attached to the label. Great results is what we are after.

-- RonEllisGaut?

I tend to think of myself more as a "logic carpenter" than as a "software engineer". I build stuff for people out of logic instead of wood, but what I do seems a lot to me like a skilled trade.

I think that programming is a line of work that got dressed up in academic drag (and called "Computer Science") because it needed to look like something that belonged in a university.

-- MichaelTrigoboff?

What would be a good definition of an engineer?

What about this: someone who takes a set of principles and applies them to a real world problem, which requires compromise rather than rote application.

Over the last 20 years of participation and observation I think the industry has developed some useful principles. They are not completely established yet, but I see them being applied more widely today than ten years ago.

-- PatrickLogan

I must admit, I've seen enough of this industry that hitting the delete button when I detect a discussion on "software and artistic vision of a better world" is a reflex action. However, in this case I revisited the thread and find the opinions thoughtful and genuine.

On the one hand, when Gabriel opines that "fear of [project] failure is fear of death" my immediate reaction is "gimme a break, fear of failure is fear of not making payroll next month". On the other hand, it has been my experience that exploration, inventiveness and the concomitant "failure" is essential to creating durable value. The trick is to balance creativity, drudgery and risk, on both a personal and project level. Patterns offer the potential for a concrete guide to what works.

The call to consider the broader impact of what we do receives new urgency with Bill Joy's Wired article (http://www.wired.com/wired/archive/8.04/joy_pr.html; see also http://www.tecsoc.org/innovate/focusbilljoy.htm for a follow-up). (Personally, I'd be ecstatic if we'd use turn signals and silence cell phones in restaurants as a start). There are opportunities to apply creativity and expertise to help non-profits. It doesn't change the world, but you gotta start somewhere. E.g. if there are volunteers to help build a mapping system for Meals on Wheels, let me know.

Finally, there is an interesting parallel between the disenchantment of some software professionals today and that of advertising executives in the 50s. Before you scoff, consider: ad execs were the original knowledge workers, recasting nuts-and-bolts products into perceptions of usage models. The advertising industry was the hot thing in business after WW2--pioneering, creative, influential, well-paid...and conflicted. It may be hard for us to fathom now, but some of those guys thought they were doing the world a service. And many of them were would-be artists in suits. There is an interesting chapter on the subject in David Halberstam's "The Fifties". "The Man in the Gray Flannel Suit" is also still worth reading.

-- FredLoney?

I'll jump in really quickly here. I've never thought of myself as an engineer. That term's always struck me as having too much of a statement of "I design something and finish it." It's not a bridge that we build that gets designed and built, then stands with minimal changes for the next 50 years.

My experience is that an application is never really finished; even when a product comes to the end of it's life it's only because something else has evolved to replace it, meaning more changes. During the lifespan of a product, if it doesn't change and/or isn't flexible enough to change, then it will quickly be overtaken by a product that can.

And Ron, I agree whole-heartedly that we cannot compromise professionalism. I believe that responding to our client's needs and being true to our profession is not mutually exclusive.

-- BradAshton?

I've found that when I'm discussing my job with people in other industries, I really don't use the word "engineer" either. The analogy I use is that learning to write software is, to me, like learning a foreign language that has relatively few words in it. There aren't any conjugations or tenses; a word means what it means. It's not easy to learn your first programming language (at least it wasn't for me), or your first foreign language (ditto), but it gets easier as you pick up more languages because the principles don't change. It's an oversimplified explanation, and it seems to get across to people.

Coding is sort of like being a language translator- you take somebody's description of what a piece of software should do, and translate it into code. Alternatively, you're taking a piece of code and translating it into some other programming language. Given a complex sentence in German, you could come up with a lot of translations for it in English. Somebody who knows German better than you do will probably come up with a translation that is clearer and more concise than yours, and that has meaning on more levels than yours, and hence more flexibility.

-- NickEby?

Interesting analogy. But I might extend it to say that writing complex software is more like translating "War and Peace" than a bunch individual sentences. As in a novel (or in the Genome) the complexity is in the interactions, not in the individual sentences (or genes, or idioms)

-- PaulBenninghoff?

True... The software community does this all the time, don't they?- translating media (books, movies, comics, strange European-elf board games) into software, creating games from their content. Anybody been involved with a commercial project like this? Were the "engineering" challenges different from those in projects where the final product isn't so well defined before the project ever begins?

As Alejandro said (sort of- don't wanna put words into your mouth), coding and testing from guidelines that somebody else came up with isn't the same as being in on the specification from the very beginning, which to me seems like the highest level of engineering in any medium. The guy who designed the Golden Gate was there when it was being built, and was still there when it was finished. Weren't his challenges greater than, say, those of the guy who had to figure out how to get the steel into place without killing anyone? (enough analogies... I'll stop now. sorry)

-- NickEby?

An anecdote, perhaps food for thought.

Our profession, like our culture, has made a Faustian bargain with technology.

In the nineteenth century, creating a building like the U.S. Capital was *hard*. Doing it required the services of a myriad of different trades and crafts: miners, boat handlers, mule skinners, masons, carpenters, architects, painters, blacksmiths, food handlers, and so on. It's not really any easier today, but any one of us could (conceivably) manage the job. Because of technology.

Technology *enables*. Building an edifice to house the U.S. house and senate could be done much more easily today. If you look around, you notice that most of us on this list live in what should pass for fifteenth-century "estates". Our lives are improved, and we empowered by technology.

But there is a tradeoff.

When you have hundreds of highly skilled experts building an edifice like the U.S. Capital, the additional cost of having them (or letting them) make it a work of art, a thing of beauty-- in addition to being merely functional--is minimal. A square mile of hand-crafted paneling and columns with finials and pilaster is not a lot more than a mile of hand-crafted drab paneling and columns.

Our technology has greatly empowered us functionally. But now the marginal cost of the beauty--in a relative sense--is sky high. Hand-crafted pilasters and finials are enormously more expensive than a square mile of machined paneling and columns.

=======

My struggle is not with our title. We are the engineers, the craftsmen, the tradesmen, the sailors who create buildings in code. We acquire our title as a description of our role. Our struggle is with our own sense of futility. We want our buildings to be elegant, beautiful, and functional. We don't always succeed, but we always do our best.

Because of our efforts, we solved a tough problem today and we helped get electricity to peasants in India, or reduced power drain on a wheelchair battery (helping someone retain mobility) or the equivalent, because DA** IT!! We do matter to lots of people. Software is unbelievably empowering.

Yet the very act of empowering reduces our own individual value. Functional (yet inelegant) software can be quickly hacked together by a spreadsheet jockey for far, far less than our had-crafted columns of algorithm. And we see every day how much concern society will have for our care, our craftsmanship, our professionalism, and our engineering skill ... just as much as we care for the skill of muleskinners and blacksmiths. Because the marginal cost of this extra care is becoming higher in a relative sense. By our own hands, we improve what we do, to better help and empower others, and we see that one outcome of our labor is mediocrity.

That mediocrity disempowers not only ourselves but everyone else too. I don't want to be mediocre. I want my efforts to do something good for the world--to leave it more elegant, pleasant and fulfilling--not less. That is my struggle.

-- RichardJohnson?

Well put Richard. I think you nailed an issue that is at the core of this discussion, which is, the conflict that emerges when the desire for fine craftsmanship bumps up against economics. Of course this only becomes an issue when one has desire to work as a craftsman in the first place. Given the number of folks I know in this business that seem have this particular frustration, I think this is a good indication of the basic nature of many of the people attracted to our profession. I can be cool working with people who understand that the business realities may not require, or even allow, the "beautiful" solution, but I begin to loose interest when people cannot envision what a beautiful solution might look like in the first place.

Going back to the logic carpenter analogy, if all you have ever done is put together pre-fab housing, how can you expect to learn the skills of a true craftsman. Wouldn't it be great if our profession had an apprenticeship process similar to what exists in other trades? In one of my previous careers, I had the benefit of working with the "old timers" as an apprentice. These mentors taught me things that I could not learn on my own. Finding similar opportunities for in the software industry is difficult for obvious reasons. In fact, for the most part, our industry does not seem to place much value on individuals whom have been in the business for many years. To bad though...

-- RonEllisGaut?

[End of pasted PortlandJavaUsersGroupThread email discussion. Start of Wiki discussion.]

When people used to ask if what we did was an art or a science, I always said "neither -- it's a craft: We produce useful functional objects that, when done well, can also be considered beautiful.

Be aware: The business people of today are much more knowledgeable about computers, and what computers can do for them. Our "high priesthood" of computer gurudom has been overthrown; we must now produce real business results on business time on business budgets. Soon, we must lean how to produce predictable results on a predictable schedule: Projects that fail "for technical reasons" will no longer be acceptable. People who continue to make such mistakes will find themselves unemployable. [XP starts to look promising to address these issues: It eliminates the possibility of projects failing for purely technical reasons.] Soon we will all be just "hired guns" -- just employees, like all the others -- who are expected to contribute to the bottom line of our employer, rather than chase after some theoretical ideal defined by our peers. Then the computer industry will be mature. -- JeffGrigg

Software is primarily a communication problem. We write instructions for machines, but everything those machines do have to go through a gauntlet of human-defined standards and translations in order to make sense. The computer might be simulating physics or chemistry or ballistics or economics, but it doesn't have to. Most of the rules we have to adhere to -- whether we're dealing with Perl or SQL or Unix or Smalltalk or ASCII -- are not absolutes; they were created by another human being at some point. (From [http://fhwang.net/writing/moving_pictures.html]: "If a computer can be considered a virtual universe, it is a universe with human hands all over it.")

This is why software tends to be different than other forms of engineering. A mechanical engineer working on a bridge needs to adhere to certain physical, non-human laws. A software engineer often doesn't have to worry about these limits; instead, e needs to ask emself "What's the best way to communicate this idea to the next person who will need to understand it?"

I'd say anyone can build dog house. A craftsman can build a house. An engineer can build a sky scraper. In software, developers are often called on to do all three without respect to their capabilitites. --AnonymousFool?