Is software engineering what professional programmers do?

Is software engineering what professional programmers do?

I originally understood and believed (what I wanted to believe, in fact) that software development trade is a branch of engineering discipline. I studied the work of Watts Humphrey, Mark Paulk and others at SEI and related organizations, looking to improve my understanding and my practice of software development. I was especially interested on these because I have been developing software for a living since some decades.

Experience by experience, I have found mayor parts of software engineering body of knowledge simply doesn’t fit with my thought process in practice. I was utterly surprised when I found that many, many practitioners –even many giant practitioners of our industry– reported similar observations. Those individuals had been practicing software development trade for many years, successfully evolving families of software products with their own hands at sustainable pace.

If software engineering is not going to be what those ‘software engineers’ do for a living, what else could be then?

Further objective research was in order, looking the seminal work of authors and trying to review the concepts from the original practitioners.

There has been surprise after surprise, many, many popular notions have proved been just plain wrong. An example, the popular software lifecycle process known as “waterfall”, which invention is typically attributed to Dr. Winston Royce because of his work “Managing the Development of Large Software Systems” is just another mal-interpretation, Dr. Royce never said “waterfall”, indeed he concluded that doing analysis, design, etc., activities (not phases), sequentially was not going to work, that each activity should be revisited.

Our industry is very, very young; many popular notions are misleading and the lack of consideration to our own history is a root source of such a condition.

Probably this condition plays a factor in many outsourced jobs to offshore development shops recently.

> "Probably this condition plays a factor in many outsourced jobs to offshore development shops recently."

How is one related to the other? What's your line of reasoning here?

Drew

12 Oct 2004 5:42 AM

I disagree. Quite strongly.

We _try_ to be "real" engineers. In the spirit of full disclosure, I should mention now that my father is a _real_ mechanical engineer. He's worked for almost 40 years in industry as a professionally accredited engineer. My last 5-6 years as a completely non-accredited software "engineer" doesn't compare.

REAL engineers design and build infrastructure that we all count on: bridges, medical equipment, and airplanes are the first examples tha tspring to my mind. Software, by comparison, is NOT largely critical infrastructure. My cousin, hooked up to machines in a hospital on her deathbed, did not count on software "engineers" to maintain her. My brother, walking down the street to work every day, does not need software "engineers" to keep him safe. I hope these two somewhat fecetious examples serve to make my point: software is not, at present, considered worthy of that scrutiny; human life, for the most part, does not depend on software.

This is changing.

Talk to anyone who has had kidney failure and depends on strange machines to be a fake kidney - there is software there! And there is serious engineering there. And those engineers are accredited, not merely engineers by job title.

This bull has two horns:
Horn 1: People don't realy count on software enough that it NEEDS real engineers.
Horn 2: There are not enough real software engineers that most consumers realize that they should demand a higher quality of service.

I completely disagree with "programming models" be they waterfall or pair programming or what-have-you because I believe that the future of software is engineering, not "how to be an efficient code-monkey". I believe that skunkworks projects (programming) are the antithesis of correct coding (engineering). I believe that most true software engineers spend less time coding and more time designing. I may be in the minority now, but I think that my belief is the future of our industry.

About outsourcing - I, personally, don't oppose offshoring. My job, if I do it right, is to make my job obsolete. That's largely the same as any other position in an engineering profession - we try to analyze and streamline process. If outsourcing either overseas or cis-sea (I made that up - like it?) streamlines, we have success. I agree that the statement in the original post was a non sequitur, though. Speaking again from my father's position as an _actual_ engineer, most of his job is outsourced now - whether in the US or outside, most of the "real" work is done by someone else and the engineers at his (Fortune 500) company are more like project leaders than hands-on individual contributors. This isn't just a software phenomenon: late 20th/early 21st century business is global. It's not about engineering; it's about business.

hi BillT,
I said probably because I am not entirely sure about how that could be related, that comment is based on some opinions or perceptions from user community about the past performance of software industry, you know published reports about failed vs challenged and complete projects.

Warning, I'm going to touch a lot of topics real fast, yet hopefully make a few big points...

As a "formally trained" software engineer, meaning I purposely went to a university for comp sci that fell under the school's engineering department and was hammered from day one there that what I was about to undertake was a carear in engineering, I have found it hard over the years to accept the "learn programming in 21 days" crowd.

That said, in talking with friends for years, I've pointed out the fact that someone who wanted to "get into our field" could buy a $500 computer and a $50 book and start learning "my field" (emphasis on "start"). That is a great "societal leveler", allowing a LOT more folks into this field than say into mechanical or chemical engineering.

It also has its downsides, as that crowd, after having written a few apps, feel they should be treated with the same respect as the "formal" crowd, as they think they can produce the same level of applications. Ultimately, that is why "outsourcing" is growing in popularity. Personally, I'm not concerned about it, as I feel more than confident that my skills will suffice my carear, but the folks that didn't fully take their carear more seriously, well, start taking it seriously...

Anyway, back to Marco's point... software engineering will always be engineering. The fact that a LARGE portion of developers (I won't call them engineers) and equally a LARGE portion of project managers don't fully understand software engineering and appreciate it and use it, well, there's a reason why our industry has had such as poor track record upon delivering solutions that meet expectations...

I think if you find Steve McConnell's "After the gold rush" you will find that you are right, we don't have "software engineers" in this country, but that is changing.

But the biggest thing is that use of the waterfall method is an indication that your software engineer isn't.

The other book I found useful was "Agile Development: A managers guide". Which was where I first found out that the whole fixation on the waterfall method was basically a misunderstanding of something that was already out of context.