Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

The Life of a Software Engineer 519

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."
This discussion has been archived. No new comments can be posted.

The Life of a Software Engineer

Comments Filter:
  • by mini me ( 132455 ) on Monday February 04, 2008 @03:02PM (#22295176)
    Using a bridge-building analogy, in my opinion the software development phase is akin to designing the bridge. You've got to present what you want it to look like and how you want it to function in a visually appealing way but the exact details aren't your concern, that's up to the engineer to figure out. In the software world, the computer plays the role of the engineer. It's up to the computer to figure out how to implement what you've described. Therefore, Canada has it right. Software development isn't engineering at all.
  • by techpawn ( 969834 ) on Monday February 04, 2008 @03:04PM (#22295222) Journal
    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.
  • by Fox_1 ( 128616 ) on Monday February 04, 2008 @03:06PM (#22295258)
    He's right. http://www.softeng.uwaterloo.ca/Current/grad_info.htm [uwaterloo.ca]

    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.

  • by Bluesman ( 104513 ) on Monday February 04, 2008 @03:11PM (#22295368) Homepage
    Yeah, show me where the software engineer's signature is from the guy who guarantees that the software won't kill anyone.

    I guess it depends on what he means by rigorous, though. At least in most kinds of engineering the problems aren't unexplored, so you have some guidelines to work within that pretty much guarantee your building won't catch on fire.

    But there's a huge difference between guaranteeing something will work and making something that pretty much works most of the time, we think. Comparing the two is slightly ridiculous.
  • by kidgenius ( 704962 ) on Monday February 04, 2008 @03:23PM (#22295618)
    Interestingly enough, that first one sounds like something in the computer is messed up....hmm, software maybe?
  • Yeah, right! (Score:2, Insightful)

    by mrchaotica ( 681592 ) * on Monday February 04, 2008 @03:25PM (#22295646)

    I'm a student of both civil engineering and computer science, and I'll tell you this: most people who call themselves "software engineers" are wankers who have no idea what Engineering actually means. So they have some UML and unit tests? Well, that's wonderful -- at least they're not just randomly bashing on keyboards. But it ain't Engineering.

    So what is Engineering, you might ask? Well, here's a clue: being an Engineer means that when you screw up, people die. It means that the thing you're making has to conform to standards for safety and performance. And those standards are legally enforced, and you have to be able to prove that your work meets them. It means responsibility. Ask people what professions they think require high responsibility, and they might say something like "doctor." Well, doctors really don't have all that much: unlike Engineers, they can only kill their patients one at a time. Engineers kill people in big groups.

    Now, don't get me wrong: I'm not trying to disparage computer science, or programming. But us programmers shouldn't pretend that our craft is anything other than that: a craft. It's not Engineering, it's not even science unless you're doing theory, and compared to either of those things we're still bumbling around in the Dark Ages.

    If I were applying for a programming job, and the interviewer told me that my title was going to be "software engineer," you know what I'd do? I'd laugh at him, and then insist he change it to something else. There are exceptions to this, of course: people who are writing code to do things like controlling space ships, performing structural analysis, or regulating a nuclear power plant can likely legitimately call themselves Engineers. But the vast majority of programming jobs aren't like that.

  • by nonsequitor ( 893813 ) on Monday February 04, 2008 @03:28PM (#22295722)
    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.
  • Re:Summary (Score:3, Insightful)

    by geekgirlandrea ( 1148779 ) <andrea+slashdot@persephoneslair.org> on Monday February 04, 2008 @03:30PM (#22295750) Homepage

    For some of us, sex was never really an option most of the time.

  • by mrchaotica ( 681592 ) * on Monday February 04, 2008 @03:34PM (#22295794)

    Many millions of dollars later in court, it was verified that the Engineer f'ed up the plans and the construction crews were not at fault.

    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.

  • by ceoyoyo ( 59147 ) on Monday February 04, 2008 @03:46PM (#22295984)
    And those are real engineers, either you or the person who signs off (literally) on your work, taking responsibility for its safety and performance.

    The programmer whose responsibility ends when he's done writing his code is not an engineer.
  • Re:Yeah, right! (Score:3, Insightful)

    by Viv ( 54519 ) on Monday February 04, 2008 @03:51PM (#22296074)
    Being called a "professional engineer" is not about how difficult your job is, it's about the level of accountability you have to assume to practice your job.

    By law, professional engineers, like medical doctors and lawyers, can be sued if their product isn't up to snuff. If it's bad enough, they can have their license to practice revoked.

    Software "engineers" have none of that burden.
  • Re:Yeah, right! (Score:5, Insightful)

    by russotto ( 537200 ) on Monday February 04, 2008 @03:53PM (#22296116) Journal

    Well, here's a clue: being an Engineer means that when you screw up, people die.


    Such drama. Lots of engineers work on non-life-critical things. That doesn't make them non-engineers.
  • by theAtomicFireball ( 532233 ) on Monday February 04, 2008 @03:58PM (#22296248)

    A profession is formed for the public good,
    Bullshit. Professions in the sense you speak are formed for the good of those people already in the profession. It allows them to control who can compete against them, both by giving them a say over who can join, and by getting the government to restrict what people who haven't joined can do.

    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.

    Although it means hobbyists could no longer tinker, we are at the point where that hobbyist tinkering could have significant implications for the international system of computing infrastructure. Why should unlicensed software authors be any different from unlicensed doctors?
    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.
  • by Dan Posluns ( 794424 ) on Monday February 04, 2008 @04:01PM (#22296316) Homepage

    I would like to have as much confidence in a piece of software as I do in a bridge, but we're not at that point yet.


    Do you suppose such confidence is either unavailable or impractical when considering safety-critical systems like nuclear reactors, medical lasers, space shuttles, missile guidance systems, etc.?

    In not every software system is it permissible to keep releasing bug fixes and new updates. It either works correctly and according to the specification the first time, or people die. Just like a bridge.

    Dan.
  • by JaredOfEuropa ( 526365 ) on Monday February 04, 2008 @04:08PM (#22296450) Journal

    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
    Software is different, in that small mistakes often have very large and far-reaching consequences. When designing software, you also have to deal with far, far more unforseeable circumstances. If we hold software developers to the same liability as we do building contractors and architects, no one would be able to profitably sell any.

    Get a guy to design you a home, and have a contractor build it. They are both liable to make small mistakes. You may be entitled to have it fixed but good luck getting them to do it. Then there's the miriad of small mistakes and oversights that you don't even notice because they do not affect you. If your building contractor used one 5" nail where he should have used a 6" one, the worst that is (un)likely to happen is that a bit of paneling falls of the wall when a truck rumbles by. In software, that one misplaced nail may cause an entire neighbourhood to collapse into matchsticks.

    Also, a lot of bugs are not that serious. Note how car manufacturers deal with liability: if there's a safety issue, it's an immediate recall. If it's an annoying blinky light, they'll fix it when you bring the car in for regular service. Don't most software companies usually (admittedly not always) deal with it like this?
  • Re:Yeah, right! (Score:3, Insightful)

    by tixxit ( 1107127 ) on Monday February 04, 2008 @04:09PM (#22296466)
    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).
  • Re:Yeah, right! (Score:2, Insightful)

    by mrchaotica ( 681592 ) * on Monday February 04, 2008 @04:18PM (#22296626)

    according to the grandparents halfbaked logic... yes. However that would also make Napoleon, Ceasar, Hitler, and Bush all engineers too because they screwed up and people died too.

    Nope, that's your half-baked logic, not mine. My statement was "if you are an Engineer, then people die if you make a mistake." Your statement is the converse: "if people die if you make a mistake, then you are an Engineer." Sorry, but those two statements are not logically equivalent.

  • by AutopsyReport ( 856852 ) on Monday February 04, 2008 @04:18PM (#22296630)
    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.
  • by cp.tar ( 871488 ) <cp.tar.bz2@gmail.com> on Monday February 04, 2008 @04:39PM (#22297064) Journal

    Software, on the other hand, has the problem of dealing (or not dealing) with unknown circumstances.

    ... and that is the other end of the issue: the users.
    As we all know, the user is the greatest unknown — the things an uneducated user could think of...

    On one hand, I see the problem with "software engineers" designing crap software; on the other hand, I see the uneducated users as just as dangerous as 14-year-olds behind the wheels. Of sportscars.

  • 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.

    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.

  • by Anonymous Coward on Monday February 04, 2008 @05:10PM (#22297592)
    I am an Canadian Engineer, with a P.Eng. even.
    Yes, you can be a Software Engineer with the proper degree.
    I've been mostly doing hardware, but now find myself in a software heavy role and I can tell you NO, it is NOT as rigourous as most other engineering professions. It should be, but it isn't. Mostly because of what the States calls "software engineers" are really just programmers.
    It's not the same.
  • by Bob McCown ( 8411 ) on Monday February 04, 2008 @05:10PM (#22297596)
    Specs? [pause] SPECS? [snicker] BWAHAHAHAHAHAHAHAHAHAAH

    Yea right. My latest specs went from "Spend some time with the latest version of the FooBar libraries we use and see whats changed" to "When will you have something we can look at and test?" in about 5 workdays.

    Specs my shiny metal ass.
  • by Anonymous Coward on Monday February 04, 2008 @05:40PM (#22298184)
    Wow... It is amazing to see how sensitive the "engineering" nerve is here. Allow me to point out a couple of interesting items regarding its sensitivity, which I would hope the readers come to realize.

    First of all, for those that are uninitiated to this, allow me to shed some light on the situation. I am fortunate enough to have lived and worked in multiple countries around the world. I had the pleasure of working with engineers, and scientists in different fields. What I have come to discover is that only in Canada is the engineering profession so damn protective and sensitive. Even more so that lawyers, and doctors, who are professionals in their own right. Anywhere else in the world, professionals from each industry treat everyone else with respect - even those that may not be professionals. Why? Because the first rule of professionalism, is to be professional to the people you are in contact day-to-day. Because that much is owed to each and every human being. However, in Canada, if you are not an engineer amongst engineers, don't expect to be treated equally.

    First thing you will notice is that engineers in Canada most often refer to themselves as "Engineers." Funny, I don't see "Bus Drivers" or "Soccer Coaches" or even "Dental Hygenists." But, you do have "Engineers."

    Second of all, as you get to know a few of them, they seem to have an interesting "better than thou" attitude. This must be bestowed on them in one of the University classes, which I apparently slept through. Oh yes - I forgot to mention that I am a professional engineer as well. :^)

    Thirdly, you will notice the little steel ring on their pinky (for more information, see here: http://en.wikipedia.org/wiki/Iron_Ring [wikipedia.org]). Generally, it is meant as a reminder of those lives lost during careless engineering practices. Great. Why, do you think, such a device is necessary? What about a doctor who does not have a little piece of jewelry which reminds him to apply proper treatment to his patients? Does that make the rest of the world's engineering practices less worthwhile than Canada's?

    Fourthly, an engineer's approach to a task should be moderated - professional. You should be capable of understanding the problem, and being able to gauge whether your skills are suitable to solve it. If not, you find someone who is better suited for the test. However, that is far from reality, as there are many many engineers that work as software developers. What is unfortunate, is that they don't understand that the 2 programming classes they took in university actually don't make them well suited for crafting effective solutions to computational problems. However, being engineers, they think that they can't be vanquished.

    Lastly is the all-important professional organization, to whom they all strive to belong to. This organization oversees standards in member skills development, cross-training, standards, and of course, safety. However, you will quickly come to realize that an engineer is never wrong! How is that? Well, if a mistake is made, it is not them who are to blame, but rather an incorrect type of material being used, or that the plans were read incorrectly. Remember kids: sh*t always flows downhill, and they think that they are the top of the pile. The professional association allows them to hide behind a large entity, with deep pockets, such that any litigation against a single individual, is futile.

    A previous poster implied that if their wall falls down, then it was obviously not an engineer who did the work. What they don't realize is that civil engineering, especially large construction projects, utilize so many standardized components and techniques developed over decades, that they are about as far from engineering as is possible. Number one reason: safety. Very few insurance companies are willing to sign off on bleeding-edge designs. And when they do, they are incredibly expensive to insure, therefore build.

    Bottom line: please unde
  • I agree, fortunately real engineering disciplines have a sense of scales. So we usually don't (over-)over-engineer. Trying to use the same design for vastly different scales if an illness of the programmer, not the engineer.
  • bullshit (Score:2, Insightful)

    by the_B0fh ( 208483 ) on Monday February 04, 2008 @05:56PM (#22298420) Homepage
    bullshit.


    I have a degree in civil engineering, and my professors stressed over and over again, if I fuckup, people die.


    In my compsci classes - oh, look, it compiles, lets hand it in.


    There's a reason they don't let Evi Nemeth teach Intro C classes - she does the right thing, and flunks people who don't do things properly.

  • Re:Yeah, right! (Score:4, Insightful)

    by DrVomact ( 726065 ) on Monday February 04, 2008 @08:42PM (#22300796) Journal

    Ask people what professions they think require high responsibility, and they might say something like "doctor." Well, doctors really don't have all that much: unlike Engineers, they can only kill their patients one at a time. Engineers kill people in big groups.

    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?

  • by ScrewMaster ( 602015 ) on Monday February 04, 2008 @08:49PM (#22300886)
    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.

    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 ... it was management that hired him in the first place, and failed to manage him effectively in the second.

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...