There's a line from a movie called "The Falcon and the Snowman" that applies to software engineers. It goes something like this:

"Like it or not, as soon as you accepted money, you became a professional."

This is how I became a "professional" software engineer almost 20 years ago. It's how most of my friends in the industry became engineers.

If you graduate from college and wish to practice as an Electrical Engineer, there are tests and apprenticeships and so on before you get that status.

To build bridges, you have to demonstrate unambiguous ability to do civil engineering and pass examinations that are objective to "practice".

Architects are licensed after passing rigorous examinations. Some states (such as California), it is very difficult to become licensed because of their earthquake specific tests.

So what does this have to do with software?

First of all, until very recently, there was no kind of objective standards needed to "practice" software. Personally, I have no college at all. I learned my "craft" in the military on my own with no help.

Software engineers come from all disciplines. I know of excellent engineers who have degrees in Mathematics, Electrical Engineering, Music, International Economics, Education, Physics, and Psychology.

The only thing that all the above have in common is that they have nothing in common.

Software requires input from both sides of the brain. Creative half and analytical half. Combining these two into one job is not even fully undestood.

Software is incredibly difficult. As in most industries, there aren't that many that are even very good at it.

The difference, is that because there are few, or no, objective standards to define programmers, it really ISN'T "engineering" but is a "craft".

So what you get are craftsmen of varying degrees of skill who have little or no objective criteria to gauge their abilities except one: the ability to "ship" (finish) a project.

Without objective criteria, there is no possibility of "silver bullet" maintenance. (Y2K is a maintenance issue) Who knows how this craftsman did his/her job?

This is not to say that I'm down on software engineers. I'm one myself. I'm a "professional" whether I like it or not. Most of the time I like it, or I wouldn't have stuck with it for so long.

The point is, that one reason why Y2K is so nebulous and uncertain, is because the "craft" of software is so nebulous and uncertain.

That uncertainty is driving me and many others to prepare. But the same uncertainty urges others to be happy. Half full versus half empty.

So everybody's job here should be to prepare himself as much as seems reasonable. And to get the word out as much as possible. Stop flaming each other, and get to work!

Jolly is a software "craftsman"

-- Jollyprez (jolly@prez.com), April 07, 1999

Answers

Jollyprez,

I doubt that modern society will survive Y2K. Some obscure tribe in the Amazon will probably take over.

However, if the modern world does somehow survive, I believe that the International Standards Organization, UN, or some other international body will mandate rigorous requirements for all computer systems. Among them will be:

* All software professionals will have to pass tests and meet standards akin to those that engineers go through today. * All public companies, government organizations, NGOs, and non- profits will have to undergo annual information systems audits like the financial audits that they go through today. These audits will require the organization to have thorough and rigorously enforced written standards. * All dates will have to be input, stored, and output with four- digit years. Windowing will probably be allowed on input, but only if the system immediately displays the date with a four-digit year before the user completes the transaction. It is possible that the date may be allowed to be stored as an internationally specified relative date number instead of as a date with a four-digit year.

Jollyprez, I would appreciate your thoughts on my comments.

-- Incredulous (ytt000@aol.com), April 07, 1999.

Jollyprez,

Please excuse how the points next to the asterisks came out. The asterisks began their lines when I wrote the comment. I guess that I needed to place a blank line before each asterisk.

-- Incredulous (ytt000@aol.com), April 07, 1999.

No doubt this has been suggested a googol times before now --

Now that memory is so cheap, why not use the Julian day as the date standard?. Applications could convert it for display into whatever format the designer chose. But the record would be common to all systems. And everybody would be on the same sheet of music.

-- Huck Finn (clueless@tower ofbabel~.org), April 07, 1999.

Hi Jolly,

I pretty much agree with you.

However, I don't agree with your implications. :)

You imply that it's possible to set some kind of standards for programming or software engineering. In some (distant) future that might be true, but software development is still in it's infancy. All attempts to certify knowledge in a fast changing field is doomed to failure.

Note the CDP on my sig line. It stands for Certificate in Data Processing -- 1963. The series of tests that I took were valid for, maybe, 2 years following the tests. But by that time S/360 came in, minicomputers were becoming widespread as control computers, and integrated circuits came on the scene. Program loaders started to become real OS's, high level languages became more sophisticated and database systems were just around the corner.

You also imply that non-certified programmers are somehow responsible for Y2K or that programmers, if certified, wouldn't have allowed management to be so foolish as to spend too few millions of dollars on hardware so that 2-digit years wouldn't have been used.

Well, some tried. :) But how do you argue with management, in 1968, when they say the systems will have been long replaced with compliant systems. They (and we) didn't know what we now know -- that files and formats are forever.

So, unless there's some way to certify not only programmers, but managers and entrepreneurs, and possibly certify prophets to tell us what trouble we'll cause by our actions, I'm not sure we could have prevented Y2K, nor am I sure we'll prevent some other, future, disaster.

-- Dean -- from (almost) Duh Moines, CDP (dtmiller@nevia.net), April 07, 1999.

Dean, you're right. I implied several things - especially about certification.

Currently there are several different kinds of certification available. Microsoft has network certification, for example.

I honestly don't know about that. If you have to have a license to practice software, that would be to my detriment! I don't have a degree, yet I'm a superior engineer and engineering manager than anybody I've worked for (with one possible exception).

So I'm actually against it as a "fix". It doesn't work. I've seen lots of people in *all* professions that don't have a clue about what they're supposed to do. Licensing doesn't fix the problem.

What I meant to lament on was the poor engineering practices themselves. And Dean is exactly right - it's because of the very infancy of our craft.

Software is an unusual occupation when compared to manufacturing, or medicine, or flying, etc. Those professions vary greatly in their complexity, to be sure. But for the most part, human bodies have systems that are known and defined. Airfoils have known characteristics, etc.

Sure they change, new drugs affect body systems in new ways, but the fundamental underpinnings remain pretty much intact. God doesn't change physics every Thursday to make "airplanes fall from the sky" (sorry guys, I could resist, but chose not to.)

Software, on the other hand, changes radically at an ever-increasing pace. What you knew three years ago (excepting certain fundamentals) is hopelessly obsolete today.

Certainly what was know 20 years ago is almost totally irrelevant in today's shops.

Finally, in addition to the fundamental underpinnings changing from beneath you, God DOES play dice with software physics.

What I mean by that is the fact that everything is so totally interconnected and dependent on every other part of a program, or system, that a glitch can cause the whole system to fail.

When designing a bridge, the physics is known and calculated in, extra support structures are added and have known effects. With few exceptions, adding additional support does not endanger the collapse of the entire structure. In a skyscraper, you make a trade off between support and weight. But these are well known.

In software it's exactly the opposite. If you put in extra "support beams", those beams actually COULD kill the whole project if they're not built correctly. An error anywhere can collapse the whole system.

That's one reason software is so hard to fix, maintain, or remediate. You have to be damn careful every step you go, and sometimes you make a change and don't know if it's going to work until it's put into action.

If every cable on a bridge will bring the bridge down upon failure, would you add more cables? Or would you make sure you had fewer cables? Hard choice.

Jolly hopes this makes sense.

-- Jollyprez (jolly@prez.com), April 08, 1999.

And society and big business is so eager to hire newly degrees IT's with no experience and schooling learned between keggers at high saleries becouse the degree counts and experience does not. They usually get what they ask for but usually not what they pay for.

-- Cherri (sams@brigadoon.com), April 08, 1999.