Slashdot Mirror
The Life of a Software Engineer
Jonathan Wise writes to share with us an interesting bit of prose describing life as a software engineer. "I am, in the States, known as a Software Engineer. In Canada we're not allowed to call ourselves engineers, although the discipline is no less rigorous than any other kind of engineering. But perhaps its for the best, because 'engineering' describes only a part of what I do. A software developer must be part writer and poet, part salesperson and public speaker, part artist and designer, and always equal parts logic and empathy."
Who tagged this Pompous... Beat me to the punch. I write code, it's my job. No more, no less. To try to give it esoteric meaning beyond what it is reaches a level of loathing that even I am not going to try to comprehend. It's a job! We may want to make ourselves seem more important based on our position because of the tech around us and being able to tell people "no" but in the end we're just beating the next level of rocks together.
Ask not what you can do for your country. Ask what your country did to you
The inability for random people to call themselves software engineers in Canada is because the Real Engineers objected to the proliferation of people with MCSE's and the the like doing a discredit to the standards of the profession, both in terms of training and work results.
So go to university for 4 or so years and you'll get the respect you crave. And the nifty IRON ring, much sexier then token ring any day.
The rock, the vulture, and the chain
Interestingly enough, that first one sounds like something in the computer is messed up....hmm, software maybe?
Sure, make light of the industry. I've been writing safety critical software for the last 7 years. You can thank the software engineers that wrote the fuel injector firmware for the turboprop on your plane for properly engineering it to always work. And while you're at it the software engineers who wrote the code running the life support systems in the ICU also deserve some props.
Not all of us work in a fault tolerant environment. Because we do our jobs well, you don't hear about the latest scandal on Slashdot. This would explain the lack of articles about software bugs causing airbags in Ford cars failing to deploy. I know you were just joking, but to some of us, software engineering is serious business.
For some of us, sex was never really an option most of the time.
You just proved his point! There was a huge court case, and it was verified as to which party was at fault. The Engineer might have lost his license over it, too, if the damages were that high. So yes, that's the difference: the Engineer was held accountable.
But software is different, for some reason. For example, do you see that happen with Microsoft? Hell no! If Microsoft were held accountable for its software like Engineers are, the company would have been sued into oblivion and Bill Gates would be in jail for gross negligence. And so would the responsible parties of every other software company.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Such drama. Lots of engineers work on non-life-critical things. That doesn't make them non-engineers.
Although the "professionalism" and "public good" argument you make has been used ad nauseam, and it has a certain attractive logic to it and seems like it should be true. But, there is very little quantitative evidence available, and almost all that there is indicates that government sanctioning of professions has had absolutely no positive impact on the quality of the services rendered by those professions, and there is considerable evidence to suggest that it may have degraded it (although it's difficult to determine causality given the number of factors that go into something like that). In other words, they do absolutely nothing to protect the common good over, and they may harm it.
Government sanctioning and licensing of professions is completely about control and prosperity of a particular group. That's now how they're justified and you won't find it in the charters or enabling legislation, but it's the reality of the situation. They are lobbying groups and industry associations all rolled up into one, with quasi-governmental powers to boot. Your statement shows a fundamental misunderstanding of the craft. Basically, every really incredible programmer/developer/software engineer got that way by tinkering. Not by taking 60 credit hours of programming classes. It's the countless hours of trying things out and figuring shit out that got them good. The classes, if they were even taken, provided a starting point. Anything that discourages tinkering prior to or in addition to formal training would have a dramatically negative impact on the "international system of computing infrastructure" because it would drastically reduce the ranks of those who actually make all the stuff work.
While I actually have issues with licensing of Doctors, I'll point out one very serious and very obvious difference: You an code on your own computer -- tinker if you will -- and have absolutely no chance of hurting anyone else. You can't exactly practice surgery on your friend safely. You can study anatomy all day long, but without being able to work under a doctor while cutting into a patient or diagnosing a difficult case, you're likely to do far more harm than good no matter how much knowledge you have shoved into your head. They are not comparable cases; there is some basis for licensing of doctors, absolutely no rational one for licensing of software engineers unless you are completely ignorant about how good coders become that way.
Now, if you want to talk about specific accreditations for programming in fields where there is a high risk of harm, such as coding for the FAA or NASA or military, I'm willing to be slightly more sympathetic to your argument, but am skeptical that it would guarantee or even improve the quality even in those fields.
There are plenty of qualified engineers designing non-"life or death" products that wouldn't agree with you. I'd hardly say a using a toilet will turn into a life or death situation, but I guarentee you some engineer took great pride in his crapper. You can say this about thousands of other common things; cell phones, car climate systems, radiators, fans, key pads, etc.. Some software is related to life-or-death (you gave some examples), but much of it isn't. The same can be said for engineered products. I can guarentee you a lot more "rigour" went into the engineering of the guidance system of most airplanes than the gas tank in my car. When your designing software, you are allowed a certain amount of failures. It would simply cost way to much to create something as complex as an operating system an expect to, literally, never fail. The same goes for something like a car. Some things are extremely complex, and there are just too many variables to have it work 100% all the time. Your goal, as an ENGINEER, is to produce something that does its job with a failure rate lower than some minimum and do it within budget. Not everything engineers touch is 100% perfect or someone loses their accreditation. Cars break down routinely, nuclear reactors go off-line, giant undersea cables get cut, roads break and crack, jet engines fail, toilets leak, etc. Software engineering is about taking the standard principles of engineering and applying them software. This is where the idea of testing, monitoring failures rates, cost models, etc. come from. The same way an engineer can produce a product with some defined failure rate, so can someone create software with a defined failure rate. What makes software engineering not real engineering, as has been mentioned, is that engineers sign their name and can be held responsible for their failures directly. Although I don't see why this can't happen with software. We should be able to design software that works within predefined limits. Just because it crashes, doesn't mean someone will get sued. GM isn't sued everytime someone's MAF sensor fails. But, if someone designs some critical, one off, software for a client and guarentees a failure rate that it is obviously not meeting, then they can sue (though they can already do this already).
I would argue that software is different for other reasons. Most software developers/companies cannot be held accountable because changes in the industry are beyond their control.
For example, when engineers design and build, they have to contend with a variety of concerns. Most of these concerns are calculable, limiting, and realistic. As a simple example of the forces of nature, wind power is calculable and only occurs within expected limits. Things are built to withstand extreme winds. But there is a threshold -- we don't build to withstand 5,000mph winds because we know it just won't happen. Wind is wind, it increases or decreases, nothing more.
Software, on the other hand, has the problem of dealing (or not dealing) with unknown circumstances. Developers cannot know that in five years, the platform their product was built on will be obsolete and unusable. Products come and go daily, and support for these products fade just as quickly. Hardware also changes on a daily basis, making it impossible to stand behind your product, the same way an engineer does his. There is no professional obligation for software developers because there are so many unknown variables that come into play.
Here's another way to look at it using the bridge example. If an engineer 50 years ago built a bridge to support the horse and buggy, not knowing that the invention of the modern-day car was on the horizon, he cannot be held accountable for the bridge's collapse under the weight of multiple vehicles.
This is akin to software development. Developers cannot predict the future, consequently cannot plan for it, and ultimately therefore cannot be held accountable for it's failure. Also... The other big reason is that a blue screen of death doesn't result in actual death.
Actually, depending on the context software is used in, it can quite quickly result in death. Planes and automobiles come to mind.
For he today that sheds his blood with me shall be my brother.
Give me a break! There is no engineering environment better specified than a computer platform. The material world never does what you tell it to and you never get to dictate how it should work. You have to go at length to make its own working to suit your needs. We have means of predicting its behavior but it always has a lot of uncertainty. The raw materials are ill-specified, initial state of the system is imprecise and the models are incomplete. Worse, future environment is usually unknowable. IOW, you never get to know the operating environment of a RW engineered system.
In software engineering, you always have a precisely defined system and if that environment isn't working to your specifications, you know that some other software or computer engineer messed up. It doesn't matter if the other guy of your own messed up backward compatibility or initial design; it is still some software engineer failing to write bug-free code to specification. The hardware changes are a lame excuse. Why does it matter if they changed the physical realization of a specification? If they did their job, your software shouldn't fail (but sometimes it still does) or they failed their job and you are not supposed to be responsible anyway. Software engineering is hard, but that is due to very complex interaction of very well specified components. Taken as a whole software environments are best specified and controlled engineering environments possible.
Gentlemen, you can't fight in here, this is the War Room!
Hmm. I thought you said you are studying civil engineering, but it sounds as though your career objective is combat engineer. Surely you know the distinction: "civil engineers build targets, combat engineers destroy them". But I think I get the idea: you're saying that engineering differs from computer programming in that engineering is an activity that has real-world consequences, while programming does not. So if you're a programmer working on, say, the targeting and guidance software for a cruise missile, then you're completely harmless. I work for the software group of a company that makes lab instruments that analyze yucky bodily fluids to see what's wrong with people. Those instruments are controlled by...software. (It runs on Windows, don't tell.) If I screw up, and a few hundred cases of Hepatitis C go undiagnosed before someone notices, well...I probably won't have killed too many people. After all, I'm just a harmless programmer...
I actually agree with you—the title "Software Engineer" is pretentious. I disagree with your apparent belief that programming differs from engineering in that only engineering can have serious—even fatal—consequences. As I tried to show with my examples, the way in which computer programs function—or fail to function—can have serious consequences as well. So what is the difference between engineering and programming?
You might invert the question: why would anyone think they're the same? I think it's correct to say that, in the most general terms, engineers determine how to construct or arrange materials to fulfill a specified purpose. In doing so, they manipulate quantifiable entities—such as the strengths of materials, the distribution of stresses, the known limits and characteristics of varying methods of construction as determined by empirical study, and so on. Programmers don't do anything like that. Programmers write code, and code is an application of logic. You might say that programmers are like engineers who build logical machines, but that's mere metaphor. Computer programs don't break because the wrong type of steel was specified for one of the gears.
So where did the notion of "software engineering" come from? Maybe it's symptomatic of an unspoken insecurity, a fear that programming isn't a serious profession. Perhaps one source of this insecurity is that programming is still a very new item in the human tool-box, and we haven't quite decided which compartment to put it in. Moreover, programming isn't like any other tool we've had before. It resembles engineering in that the programmer does build something, though no materials are used in the building. It resembles mathematics in that it's logical, but it isn't bound by mathematical rigor. You can't "prove" a program—except perhaps in a—completely impractical—theoretical sense. (Of course you can test programs, and rest assured that where I work, we have very thorough software design and testing protocols.)
And now the next contentious question: are computer scientists really scientists?
Great men are almost always bad men--Lord Acton's Corollary
Let us also not forget that the ultimate responsibility for a major team effort failing is usually managerial. There are processes that any professional engineering team's leadership puts in place in order to make sure the end result is as expected. That's because nobody is perfect and mistakes get made. So, it's easy to pick on a single individual, like the aforementioned civil engineer. One should ask why there was no proper design review (and if there was, why did they sign off on it?) In any event, a properly structured real-world project has layers of checks and balances. Modern engineering projects may have hundreds of individuals working on them, and for anything other then chaos to result, there has to be direction, there has to be oversight, there has to be management.
... it was management that hired him in the first place, and failed to manage him effectively in the second.
When you get right down to it, when a big project fails the grade (like, say, Vista) it's the people who get the big paychecks that should be held accountable. That's why they get the big paychecks! They're supposed to make certain that the development and support staff are competent, and set up systems that provide adequate assurance of quality. Failure to do that is not the fault of the individual engineer, but is a systemic issue with all the fingers pointing to the top. Managers (particularly incompetent ones) will usually find a scapegoat in the form of an engineer, who they can point to and say, "See? It was all his fault!" That conveniently ignores that fact that, even if said engineer is a total bumblefuck
The higher the technology, the sharper that two-edged sword.