You've progressed successively from sarcasm, through elitism to ad homiem attack. I was trying to be nice, and give you the benefit of the doubt, but I strongly suspect you're trolling now. In any event, I'm getting tired of this debate: this will be my last reply.

If you believe that programming is "semi-skilled", and a branch of electronic engineering,

First of all, "semi-skilled" was the term that you had used to denigrate the skillsets of certain non-programmers. I deliberately put the words in quotes because I was quoting you, and because I wanted to demonstrate to you how that view was as unfair. If you really don't like the term, feel free to stop using it. No, I don't believe programmers are semi-skilled: any more than I believe that anyone else is "semi-skilled". I object to the term itself as categorization as excessively perjorative and largely unhelpful. Most people posses a wide range of different skills at different levels in different areas. No one is good at everything.

As for the second half of your objection, I stand by my claim on the basis of elementary formal logic. Creating an electronic computer, and configuring it to perform a given task by encoding a computer program is by definition electronic engineering: it's engineering an electronic device that produces the desired results, given the desired inputs. The configuration half is clearly a subset of whole process: this act of configuration if called programming. So, yes, both I and basic formal logic both agree that programming is a subset of electronic engineering. It's hardly an abstract statement of faith.

Software has no equivalent unless you are going to suggest that putting a new writable CD in the drive or paper in the printer is a "software mainenance" task? Compiling a kernel is a software maintenance task. Editing a configuration file is a very simple software maintenance task, that a very minimally trained person can do. This is akin in my mind to topping up fluids or other acts of simple maintenance.

Like other disciplines, there's a clearly a continuum of skill sets here. Contrast "Stewardess, Pilot, Aircraft Engineer" with "Secretary, Sysadmin, Operating Systems Programmer", and note the similarities.

Software maintenance is more akin to re-engineering the suspension when it fails to meet the ride or handling characteristics required; or altering the fuel/air mixture to compensate for high altitude use.

This is sometimes true. Quite often, however, it is not. Sometimes it is very much akin to routine maintenance. Solving the Y2038 "bug" is an example of routine operating system maintenance.

To be able to perform this type of maintenance requires the maintainer to have a full understanding of the principles that underly the original design in order that they can re-engineer the appropriate components to compensate for the inadaquacies.

I disagree. The individual assigned to code maintenance doesn't need to understand all of the original design. He just needs to know how his code change fits in. The senior software architect can tell if new business requirements will contradict any of the fundamental design principles of the original design: because he documented them carefully when the code was written.

And if that senior design architect has designed a good, simple, modular system, and documented properly, he will know which changes to which sections of code can and can't be assigned to a junior coder, an intermidate, or a senior coder, and the degree of re-engineering required.

You don't need a Ph.D. to edit a configuration file, to recompile a kernel, or to uncomment a #define setting in a header file. You don't need a master's degree to write a simple test script to measure return values against a series of constants. The project manager's job is to assign the right person to the right job. The senior architect (and/or senior programmers') job is to give the proect manager enough information about the codebase to make that decision correctly. (If the project manager is a senior programmer, his job is often a lot easier).

The role of software mainenance often requires greater skills than the original programmer, because an underlying principle of software mainenance is that of "least change".

The principle of "least change" is a vehicle for the real requirement of code correctness. Simple, verifyable code is not only easier to prove correct, it usually includes less interdependancies than more complex code, and hence, fewer changes during maintenance. The principle of least change tends to support simpler code, not more complicated expressions. I maintain my belief in simple, provably correct code.

Don't just take my word for it, though. Go and ask experienced programmers who program mission-critical systems (the kind where lives depend on code correctness), what they think of simple systems, and what they think of complex ones. Ask what their opinion of "baby code" that just happens to work, as opposed to any more complicated form of expression. Ask them how important proper documentation, and proper process is to them. Ask them if they maintain tiers of development and maintenance staff. Listen to what they say. Then get back to me.

Often the easiest way to correct a bug would be to re-write a large swath of code surrounding it. Doing so entails huge risk, because of knock-on effects, and huge cost, because the larger the scope of the change, the more re-testing and proving requires.

This is less likely if the code-base is not a rat's nest of brittle, self-referential, "clever" algorithms, coded just to appease ego. Sorry, but I've seen too many of those lately. Consider a system that encodes a finite state machine for no apparent purpose other than an obfuscated codebase. (If were an actual language to match the automata, and if that language were well documented, and useful for some (any!) programming related purpose, I'd withdraw my objection.)

On the other extreme, note that when the code relies upon fewer assumptions, fewer changes are required to fixed the codebase when those assumptions change. If the original design is sufficiently clean and modular, there will be much less need for subsequent ad-hoc redesign.

As a positive example, when someone in the UNIX world needs to deal with the Y2038 bug, they can hire a junior coder to edit one line in one header file, and then recompile all the binaries. No overpriced "Y2K" style consultants are necessary, because the code was engineered to be maintained in the first place. The problem can be "fixed" even by someone who is not a skilled programmer. That's precisely because someone who was a skilled programmer decided to make maintenance easier, even though it wouldn't be an issue for the next few decades. That's good design. That's what I'm talking about.

The single biggest source of errors and unnecessary costs in software are those that come about as a result of viewing the mainenance role as a second fiddle, lesser skill. It isn't.

I disagree. I think the single biggest source of errors and unnecessary costs are those that come about as a result of excessive code complexity, poorly architected code, and code that wasn't designed to modular and maintanable. For reasons of simple economics, a given maintenance role should not be filled by anyone significantly more (but never any less!) skilled than the job actually requires. Assigning to much or too little expertise is a waste of manpower or a waste of time, respectively.
--
Ytrew