Paul D. Stachour wrote:
> As one who has been writing programs for over 30 years, in a variety
> of languages, systems, and hardware, I agree with Robert:
> There are very few Software Engineers available.
> Unfortunately for our profession, many of the people who call themselves
> software engineers know only one language, for one OS, one one hardware.
This is exactly what I have seen in software projects, but I have not
yet totally understood the reason. Maybe someone can help me with
Mike Feldman says in the preface of his book about datastructures that
he prefers the term "software developer" over "software engineer"
(please correct me if I misunderstood), I fully agree with this.
In larger software projects there seems to be a strong tendency to
separate tasks which should be combined: the Software Engineer does
software "concepts", often on very general level and vague, produces too
general formal documentation, and then a bunch of "coding experts", aka
hackers, are almost randomly picked up, put in front of a workstation
and produce some code....
The code represents exactly what the coders think the software should
do, mostly they even did not read the formal documentation, because they
claim it is incorrect anyway, and totally unreadable.
The result is left to your imagination.
As far as I can see it one of the reasons is that people without sound
practical experience are promoted to software engineers and are happy to
"never have to touch a piece of code again". So the gap between the
general design and the real product becomes wider every day. Only the
dumb guys do programming all their life (don't misunderstand me, I am a
programmer, too, and am quite hurt to feel like the dumb guy, but this
is how I feel quite often). For background information see the "Dilbert
Another point is that management often thinks "he got a PC, had a
beginner's course in C, so he can do the programming job". There is only
little understanding of what a good programmer must do, and often the
need to find a job for people.
So apart from that drastic description of everydays software life, what
can be done to avoid that gap between the software engineers and the
real product, especially in larger projects??