Bruce F. Webster

In my earlier post on the “thermocline of truth“, I wrote:

Second, IT engineers by nature tend to be optimists, as reflected in the common acronym SMOP: “simple matter of programming.” Even when an IT engineer doesn’t have a given subsystem completed, he tends to carry with him the notion that he whip everything into shape with a few extra late nights and weekends of effort, even though he may actually face weeks (or more) of work. (NOTE: my use of male pronouns is deliberate; it is almost always male IT engineers who have this unreasonable optimism. Female IT engineers in my experience are generally far more conservative and realistic, almost to a fault, which is why I prefer them. I just wish they weren’t so hard to find.)

Now, a post over at the Wall Street Journal cites what I think is a more controversial (and harder to support) claim — by a female VP of Engineering — that female programmers tend to write clearer and better-documented code than male programmers:

Emma McGrattan, the senior vice-president of engineering for computer-database company Ingres–and one of Silicon Valley’s highest-ranking female programmers–insists that men and women write code differently. Women are more touchy-feely and considerate of those who will use the code later, she says. They’ll intersperse their code–those strings of instructions that result in nifty applications and programs–with helpful comments and directions, explaining why they wrote the lines the way they did and exactly how they did it.

The code becomes a type of “roadmap” for others who might want to alter it or add to it later, says McGrattan, a native of Ireland who has been with Ingres since 1992.

Men, on the other hand, have no such pretenses. Often, “they try to show how clever they are by writing very cryptic code,” she tells the Business Technology Blog. “They try to obfuscate things in the code,” and don’t leave clear directions for people using it later. McGrattan boasts that 70% to 80% of the time, she can look at a chunk of computer code and tell if it was written by a man or a woman.

I’m not sure that I could make the same claim without some serious research into a broad range of coding samples. But the article is worth reading for the comments that follow it, which (as you can imagine) are quite intense.  ..bruce..

As I’ve mentioned here before, I’m writing a book called Surviving Complexity. Many of my posts here at this website have adapted from materials I’m writing for that book.

Well, now I’ve been hired by Ziff Davis Enterprises to write a weekly column on IT Management for the online version of Baseline. That column is titled “Surviving Complexity” and, again, draws upon work I’m doing for the book. My first column is up: “Lies, Damned Lies, and Metrics (Part I)”; here’s the opening paragraph:

When Capers Jones published Assessment and Control of Software Risks (Yourdon Press, 1994), he identified the most serious software risk in IT projects as “Inaccurate Metrics,” and the second most serious software risk as “Inadequate Measurement”. I remember being startled when I first read that back in 1995—they certainly weren’t what I would have chosen—and other authorities in the field criticized his choices. Yet, in the intervening years, I have moved closer and closer to Jones’ point of view.

I’ll still be writing here, both with materials relevant to Surviving Complexity and with my on-going revisions to The Art of ‘Ware. But please feel free to check out the new column. Thanks. ..bruce..

One of the books I’m currently writing is Pitfalls of Modern Software Engineering, a greatly expanded and updated version of a book I published back in the 1990s. I’ve been posted new and revised pitfalls over at my Bruce F. Webster & Associates (bfwa.com) website. To make the pitfalls a bit easier to browse, I’ve now added a page to that website that lists all the pitfalls posted to date, with link to their individual entries. Just FYI. ..bruce..

[Copyright 2008 by Bruce F. Webster. All rights reserved. Adapted from Surviving Complexity (forthcoming).]

And so, from hour to hour, we ripe and ripe,
And then, from hour to hour, we rot and rot;
And thereby hangs a tale.

– William Shakespeare, As You Like It, Act II, Scene vii.

I have observed a pattern (or anti-pattern) in IT engineering that looks something like this:

Let’s call this the arc of engineering, since that’s more compact and elegant than the strangely shaped curve with what appears to be a single inflection point of engineering. “Arc” in any case conveys the essential sense: that system quality (however you wish to define that) rises over time to a peak value and then starts to decline.

Read the rest »

Today’s New York Times reports that Japan is “running out of engineers“:

After years of fretting over coming shortages, the country is actually facing a dwindling number of young people entering engineering and technology-related fields.

Universities call it “rikei banare,” or “flight from science.” The decline is growing so drastic that industry has begun advertising campaigns intended to make engineering look sexy and cool, and companies are slowly starting to import foreign workers, or sending jobs to where the engineers are, in Vietnam and India.

It was engineering prowess that lifted this nation from postwar defeat to economic superpower. But according to educators, executives and young Japanese themselves, the young here are behaving more like Americans: choosing better-paying fields like finance and medicine, or more purely creative careers, like the arts, rather than following their salaryman fathers into the unglamorous world of manufacturing.

The problem did not catch Japan by surprise. The first signs of declining interest among the young in science and engineering appeared almost two decades ago, after Japan reached first-world living standards, and in recent years there has been a steady decline in the number of science and engineering students. But only now are Japanese companies starting to feel the real pinch.

Read the whole article.  ..bruce w..