Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.

Recent Items
 
A Feed Too Far
 
Security is a Programming Problem?
 
Ending the Madness: Deja Triple Vu
 
Your%20Message%20Here
 
Just Ducky, Simply Ducky. And You?
 
All Clear: End of Test #1
 
Why Learn Assembly Language
 
Linking the Atom Feeds
 
Button, Button, Where's the Update?
 
Do We Have a Firewall or a Development Web?

Archives
2004-06-13
2004-06-20
2004-06-27
2004-08-29
2004-09-05
2004-09-12
2004-09-19
2004-10-10
2004-10-24
2004-11-07
2004-11-28
2004-12-05
2004-12-12

To Engineer is to Tinker?

Visual Studio Magazine - The Software Architect - The Software Practitioner Triad.  (disclaimer: This article is a year old and I have been unsuccessful finding much clarifying discussion.)  I love Alan Cooper's books.  I respect his sensibilities and the insights about interaction design.  And I very much appreciate this:

"Today, Web designers are called programmers, programmers are called engineers, engineers are called architects, and architects never get called.  Not only are our titles mixed up, but our community of software practitioners is also deeply confused about the roles we play.  The confusion is even worse in the minds of the businesspeople who hire us and set our budgets and schedules."

I also nod knowingly over an assertion that programming is not the same as engineering.  That is, until I am told what the difference is.

I'm here because Chris Sells recently chose to align with Cooper's appraisal in this manner:

"[There are] three different folks needed to design and build software:

• Architect: responsible for determining who the user is, what he or she is trying to accomplish, and what behavior the software must exhibit to satisfy these human goals.
• Engineer: technical problem solving via experimentation, not fettered with the demands of producing release code.
• Programmer: producing a shippable product, consisting mostly of protective code that rarely--if ever--executes, but is dedicated to supporting obscure edge cases, platform idiosyncrasies, and error conditions.

I've done all three, but am happiest with architect and engineer. Where are you in your current job? Where do you want to be?"

Then commentors on that Chris Sells 2004 August 16 piece continue to embrace this nomenclature by placing themselves on this triadic grid.  The strongest alignment is in the June 26 piece by Phil Weber, in which this view of engineer is positively glorified.  Guys, being an engineer does not mean not knowing how to deliver to a schedule, OK?

Meanwhile, I'm thinking "Alan, what have you done?"

Let's review the bidding.  In "The Craft of Programming," Cooper's previous column, there is a nice description of programming as craftsmanship:

"Programmers are craftsmen and craftswomen.  They are commonly thought of as--and frequently titled--engineers, but few working programmers 'engineer' things.  Most build software.  They craft it into existence."

It is, of course, not everything that programmers and, especially, professional software developers do.  But it is arguably different than engineering:

"The engineer was the educated, trained expert who designed the manufacturing processes: the 'engines' of industrialization.  The engineer was clearly the most highly skilled person in the industrial-age hierarchy.  But engineers don't actually build things.  They solve complex and demanding technical problems necessary to building things, but they leave the actual creation to others.  Engineers don't build bridges; ironworkers do.  Engineers don't build software; programmers do."

This is fine as far as it goes, and Cooper has a great deal more to say in honor of craftsmanship, using the example set by his electrician father.  The entire article is valuable for an appreciation of craftsmanship.

Ignoring the nudge about "actual creation," I can be satisfied with engineers as highly-skilled at solving problems necessary to building things.  How can we avoid the leap from here to untramelled experimentation (what I call tinkering in my choice of title) as engineering?  Cooper provides further useful characterization:

"Engineers primarily devise manufacturing solutions and solve technical problems. They're rarely responsible for the actual construction of things. For example, a structural engineer devises solutions that allow a building to stand firm, but he or she lives in a world of paper and mathematical models and won't lift a finger to weld steel or pour concrete. It behooves the engineer to try numerous solutions, exploring dusty corners of the problem to find opportunities for improvement. It behooves the craftsman to stay on well-known ground and to avoid costly experimentation. The engineer works on paper prior to construction, and the craftsman builds the end product. The engineer throws away paper; the craftsman throws away time and money. Both are prized for devising creative solutions to difficult technical problems, but craftsmen are most highly prized for constructing sound artifacts quickly, efficiently, and expertly, with a minimum of waste and a maximum of predictability."

Programmers and erstwhile software engineers should study this closely to locate themselves in here and determine whether their practice of skill or craft measures up.

I think the muddle and the false contrasts that can be taken away from these simple statements have to do with confusion of problem solving, experimentation (and the implication of costliness), design, and differences in scale.  Architects, engineers, and programmers/craftsmen solve problems.  All look for soundness, constructability, and deliverability, at different scales and in different levels of abstraction.  For example, consider the following triad:

• Architect: Why? - addresses the setting and the purposive requirements for an architected artifact, with attention on the problem space and how a solution must address it
• Engineer: What? - addresses the nature of the artifact and the construction process that will secure and maintain it with attention to valid fit of solution with the architecture
• Programmer: How? - a problem-oriented activity in which the components of the artifact are crafted, integrated and verified

I am not wedded to these distinctions.  It is just-another-triad (I won't say hierarchy here) with familiar labels.  Also, anyone who possesses mastery in one of these non-exclusive domains must also appreciate the contribution of the others.  These practitioners must be able to talk to each other and consult with each other and honor the different expertises that are being brought to bear.

If Cooper is not observing these characteristics in development of software products, to that degree not only is architecture absent, so is there lack of engineering.  To the degree that practitioners mischaracterize engineering, engineering has been absent from their lives.  Results in each of these domains involves problem solving and choice among alternatives to optimize to the situation at hand.  Reach and depth may differ.  Relationship to the world of the user may certainly differ.

And speaking of false contrasts, here's one cheap shot that doesn't separate the engineers from the programmers at all: "Engineering--real engineering, not programming--is problem solving divorced from the needs of actual people."  It's further down the page from the editor/interviewer remark "Reminds me of a saying I heard decades ago: 'In the course of every project, it eventually becomes necessary to shoot the engineers--and begin production.' "

I'm disappointed and saddened.

When my father labored in a foundry, he'd bring home talk about the engineers.  When he worked on the sales floor of a furniture store, he brought home talk about management (and customers).  When he carpented, he talked about electricians.  I want to come back to the recognition of "different folks needed to design and build software."  And if we are going to recognize software engineers, let's at least talk about software engineering.  I guess I'll leave it at that for now.

---

I am baffled to see, in other articles that I read, so much conflation of programming and computer science, something that even sucks software engineering under the same tiny umbrella, sometimes in the same breath.  It hadn't dawned on me that along with that peculiar reduction to "I code, therefore I am" and the idea that the code is the product that there are now a full rack of baseless contrasts by which engineer and architect are dispensed with.  Maybe, in all of the articles I am noticing, it is just an effort to identify and emphasize the importance of what we know the most about, our own rôle.  It looks like we lost something along the glorious stampede to the present state of immaturity.  I think it is going to cost us.

---

Reposted 2004-09-11T05:17Z This page is in UTF8, but some times the browser has to be told that.  I made it easier to have this be presentable whether or not the browser figures it out on its own.  There's a lesson in system coherence here, but we'll talk about that another time.  I also missed one place where Unicode dash symbols occured, so I used this occasion to nip those, wordsmith a little, and have the Atom feed regenerated correctly.

posted by orcmid at 9/7/2004 01:22:45 PM, rating data by NewsGator Online