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
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?
Tell others about this article:
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."
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.
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.
"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…