This is a rather jumbled expression of my opinion and feelings about the "Software Engineer" vs
"programmer" issue. A more cohesive expression will take much more time, dialogue, and reflection, which
might be better off done in some other location.
Engineers of all types work with available parts, tools, and techniques, hence there is a structure within
which they must work. Their projects stay within well defined boudaries. Programming can exceed the bounds
of currently defined structure. New concepts and ideas are allowed.
I have been told that a software engineer was a coder, that is, a SE put the pieces (instructions) together
into a command stream based on a design already created, just like an Electrical Engineer building a dam.
Programming, when including requirement analysis and design, is a combination of science and art. Whole new
concepts often result.
I guess what it boils down to is whether you wish to believe that programming should be so dissiplined that
the creative nature of programming gets stifled. Some people will try to convince you that there is no
room in a scientific world for art. Yet it is the artistic nature in us that is the genesis of new
concepts and new sciences.
Or maybe it is because I have been in the programming industry almost since it began and am adverse to the
change implied by trying to change the nomenclature from an implication of art to one of science. Not that
the change implied is in itself bad, but that the attempted change implies a "one or the other" idea. Such
polarization ignores the need for creativity in the creation of any product.
How many bridges have you seen declared complete that you had to stop midway across (baring other intervening
events, such as wind, earthquakes, traffic accidents, traffic load, etc.).
I have seen many supposedly "dynamic design processes" that were worse than your example of a bridge that was
uncrossable. Everyone is trying to increase the productivity of programmers (with plenty of justification, and
my best wishes), but this, too, is an art form, perhaps even more so since many such processes seem to fail its
own scientific tests. So far I have only seen three reliable means of reducing design and coding errors: 1).
Constant education of the programmers, plenty of reviews with knowledgable peers and the resultant crossfeed of
information, ideas, and techniques that result from them, and lots of testing.
"This is the process, so this is how it has to be done!" has resulted in the death of too many good product
ideas. A process is only dynamic if the process can be easily changed. "Process owners" seldom are willing to
see their processes change. When a small group of people are involved it is easier to get arround the flaws of
a process (basically by ignoring the flawed rules). Larger groups more often get bogged down by such flaws,
which adds to, instead of reducing programming errors.
Cheers,
Jack
Stardock Forums
