[Discuss] Fwd: Re: Programming vs Engineering
Mark Woodward
-------- Original Message --------
Subject: Re: [Discuss] Programming vs Engineering
Date: Sat, 21 Jan 2012 22:13:24 -0500
From: Mark Woodward <ma...@mohawksoft.com>
To: Richard Pieri <richar...@gmail.com>
On 01/21/2012 04:37 PM, Richard Pieri wrote:
> On Jan 21, 2012, at 1:39 PM, Mark Woodward wrote:
>> Does anyone have any comment?
> Yeah, but it's more rant than anything else. You've been warned.
>
>
> The title "Engineer" has a specific, legal meaning. Professional use of the Engineer title requires rigorous education, testing, internship and licensure. None of these exist for professional programmers. Therefore, there are no Professional Software Engineers, regardless of what is on our business cards[1]. All of this also applies to the "Architect" title. Architects have similar education and testing requirements to Engineers, and like Engineers they must be licensed to practice professionally. Use of the Engineer and Architect titles for computer specialists is nothing more than aggrandizement.
I have to disagree with you here and while I do see your point about
licenses, I truly think computing is too immature to establish the
requirements on which you could establish a licensing process. For
instance, we don't even have a standard set of measurements nor do we
have a standard language in which to express computing engineering concepts.
Programming languages and methodologies are still in flux and under
development. How could a bureaucratic organization in charge or any such
licensing process not become a useless albatross?
Before we were a "nation of laws" and before we tried to quantify and
regulate everything, "engineer" was a verb and an "engineer" was one who
did it.
> In my book, your exemplar "good software engineer" is really a good programmer, and your "good programmer" is anything but good. He is terrible. He'll write "correct", "clean" code that will be five to ten times slower than the good programmers' painstakingly optimized code. Then he'll go and rewrite their code to "clean it up" to match his own and check it in without telling anyone. Then the next release candidate suffers catastrophic performance problems and a mad scramble to figure out why ensues. Someone at a previous job of mine did this, and the senior management was not amused. Bad programmer, no biscuit.
> Rant off.
I have had similar experiences, but of a different character.
Programmers who create reams of code that "works" and make the release.
Gods help you if you want to figure it out or need it have multiple
instances. The practitioners of this work get praise, but the correctors
of it get criticized. When all is done, the crap work was fast, but the
engineered correction takes time. Management doesn't see the time of
"engineering" as valuable because, at the end, it doesn't seem like it
does anything differently. When you add a new feature that depends on
the previous engineering, the work is not factored in.
I also disagree about the bad programmer. Someone who can create
something that works has a talent. It is not my way, but I can see it.
If you read "programmer" as a noun of the verb "to program" then they
are in fact programming and they are good programmers. Engineer isn't a
title, it is a verb and one who does it is an "engineer." It generally
means applying science and ingenuity to solve problems.
Take solace in "software engineer." There is no established definition.
It is up to us to establish what that means. Doctors had to form
professional groups to keep others from calling themselves doctors.
_______________________________________________
Discuss mailing list
Dis...@blu.org
http://lists.blu.org/mailman/listinfo/discuss
Matthew Gillen
> I have to disagree with you here and while I do see your point about
> licenses, I truly think computing is too immature to establish the
> requirements on which you could establish a licensing process. For
> instance, we don't even have a standard set of measurements nor do we
> have a standard language in which to express computing engineering
> concepts.
>
> Programming languages and methodologies are still in flux and under
> development. How could a bureaucratic organization in charge or any such
> licensing process not become a useless albatross?
I concur. Things are so bad in software engineering in terms of broad
agreement of best practices and such that many organizations are happy
to have CMMI compliance. The funny part (not ha-ha funny) of course is
that CMMI is about /managing/ software projects, not /doing/ them.
I would go much farther than Mark did. Yes, from the perspective of
being able to duplicate successes, software engineering is very
immature. But from another point of view, software as a whole is
probably the most varied and complex field there is right now. Computer
science topics are creeping into virtually every field of study.
Software is doing things today that most people hadn't dreamed of 10
years ago. The key point is that the 'hard problem' that software is
trying to solve is too much of a moving target.
The kinds of things you need to think about when you're reading a few MB
off a local hard drive are radically different from what you need to
worry about when you've got terabytes of data on a SAN/NAS.
Licensing is about having well-established / well-known ways of solving
problems. The problem-space for software is still expanding. I don't
see how you could come up with licensing until your problem set is
stable (unless you take a very small subset: e.g., JBoss development, or
Win32 driver development).
Matt
Bill Horne
> Licensing is about having well-established / well-known ways of solving
> problems. The problem-space for software is still expanding. I don't
> see how you could come up with licensing until your problem set is
> stable (unless you take a very small subset: e.g., JBoss development, or
> Win32 driver development).
In computer-related fields, certification has been a substitute for
licensing in many areas. The problem, however, is that the technology
has always changed too quickly for any single certification to provide a
potential employer more than a general indication that an employee is
able to acquire a lot of task-oriented knowledge. The issue, in a
nutshell, is that there is no consensus about the professional standards
that should apply to software or computer engineers, and therefore
employers have found themselves settled for applicants who are more
likely to do /some/ things well, even if their knowledge locks them and
their employer into a single vendor's architecture.
I am a Certified NetWare Engineer - for version 3.12 of Novell NetWare,
which was being shouldered aside by Windows NT at the very time that I
was taking the seven exams that qualified me to write this sentence. I'm
also an Microsoft Certified something-or-other: a credential that
arrived unannounced in the mail after I took my first two exams for
Windows 2000 certification, just as XP was taking over desktops and
Windows 2003 (or was it 2002?) was being moved into server rooms. The
certifications of today have the same problem: employers have learned
that they are an indicator of skills and training which are likely to be
obsolete before their holders finish filling out their W-9 forms, and
job-seekers are more and more leery of being locked into a single
technology silo that can be shoved aside as quickly as Novell was in 1996.
The difficulty of licensing is that there is no agreement about what
constitutes "competency", for the same reason that certifications remain
popular: employers have found out that "experts" are easy to find, but
that "best practices" are not a substitute for the task-oriented
knowledge needed to make things actually work. Doctors and lawyers have
an advantage: the glacial pace of human evolution in the first case, and
the slow pace of legal change in the later. With fields of study that
change so slowly, task-oriented knowledge /is/ generalized expertise,
and I don't feel it will be possible to agree on licensing standards for
software engineers unless, and until, the pace of change slows to one
which spans multiple generations of practitioners.
Bill Horne
--
Bill Horne
339-364-8487