Is Software Engineering in the US Dead?

On the local PJUG mailing list, Steve Hall posed a question:

I am interested in PJUG memberÕs opinions on whether software engineering as a career direction in the US is still viable, or whether this is a dying industry as software engineers cannot compete in a global economy?

It generated lots of comments, and I didn't want to capture them all, but I did want to capture some of my thoughts on the future of software as well as the concept of software quality:

As I've been following this thread, I'm struck by how much the word quality has been bantered around. We feel that we can justify our higher cost due our better quality, but this strikes me as not very tenable. I mean, how often do each of us shop at Walmart for our sound systems as opposed to Echo Audio or Bose, What about Winco vs New Seasons, or… you get the picture. As both business-people and consumers, we often choose cheaper Chinese goods instead of better quality versions from the U.S..

I have a toaster made in 1950 that still works, but few people are willing to spend extra money for a perceived increase in quality.

Of course, some people will spend more on something that they feel will last longer or has another aspect of value. People who purchase Macs typically say the extra value they feel they are getting is worth the extra cost. But value is a difficult metric, and while one person may claim that a Mac is better, another can disagree with the same reason.

While it is beside the point, I have found plenty of code produced by American engineers that lack quality.

My point isn't to start up any flames (esp with your Mac and PC zealots out there ), but to get us thinking that maybe we, as a community of engineers, could come up with more tenable arguments to back up our quality rationale:

• Language, timezone, culture, and communication.
• Long-term support and maintenance
• Produce code closer to requirements quicker
• Better able to render business requirements into business code

Leave it to me to change a discussion towards philosophy, eh?

---

Comment

I've stayed out of this too, because on lists and forums we preach to the choir. This kind of information needs to get to decision makers. It's the same reason I've really reconsidered speaking at user groups and decreased my article output - the attendees say "Great," use my ideas, and I get no work out of it. I'm considering reaiming at manager groups. Now, I don't do things just for monetary results, but…

Anyhow, I've seen this stuff first hand, and there's politics as well as real considerations involved. I proved to a Fortune 100 corporation that not only was our code "better" but cheaper overall. The reply was "it's a corporate direction," and they returned to offshore. So you have inertia and often someone upstairs will look bad, so no go. It turns out the actual money isn't always that important.

But, the real reason I responded to your post is that many of the components you listed are in my definition of quality; To cliche land ( but the reason most cliches exist is because they are true ) "Quality doesn't cost, it pays."

---

Comment

Great points Howard,

I think the key when trying to influence high level decision makers is the old acronyms TCO and ROI. I find that senior management respond well to these metrics, and any conversation needs to incorporate these metrics, else it won't get their attention. Your list below are the building blocks for these.

---

Comment

Jumping in late on this topic, but I wanted to chime in on the philosophy of quality. Bad software is like pornography… we all know it when we see it.

But that is the issue here - the software we build is in a black box. Anyone can make the crappiest spaghetti code, but so long as the customer can push the button on the box and the light comes on, the job is done. So given time, money and quality - pick two. Unfortunately, quality is hidden in the box, so companies tend to squeeze time or money. I think quality is of the utmost importance, as I think it has the greatest impact on cost.

I think open source software magnifies this point, as it isolates quality from the time and cost factors, as it is freely available and turn-key. If you choose to integrate OSS libraries, you effectively outsource a segment of your application to the open source community. In the absence of cost and with minimal implementation time, quality is the only factor. The more you leverage a particular library, the closer you tie your applications quality to that of the library. Quality is the primary factor in choosing between two libraries.

Outsourcing is the polar opposite of open source, and in-house development is somewhere in between. Outsourcing companies must be motivated by dollars which means they will sacrifice quality, or as described in an earlier email lengthen timetables. Whereas open source developers want to fulfill their need for quality software, and so commit their time without money. In-house developers balance their time between quality and cost, because ultimately they will have to maintain their own mess. So you are ultimately making a decision where you will spend your money, and the only factor is quality, assuming that which ever option your choose you will get your black box with a button and the light will turn on. The only other trade off is dollars for time (takes longer to communicate over distance, language, etc.)

Is more maintenance work or initial bulk coding being outsourced? I can see outsourcing the maintenance programming, but not the initial core works, which can be critical to a projects longevity, where quality becomes a multiplier for any future work.

---

Comment

"Quality" of a mass produced good isn't comparable to "quality" of a crafted item like software. Whether your bobble head doll is stamped out in China or the US makes little to no difference to its quality. There's nothing resembling the kind of teamwork required in software, communications required, design skills, etc. There's no "essence" as Brooks put it in stamping out a bobble head doll.

It's fine to change the discussion focus, but let's pick an analogy that's closer to apples to apples, rather than apples to lawn mowers…