My work can affect peoples safety, and my employer prefers rapid development over quality?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
19
down vote
favorite
I work at a company where bugs in my code could affect peoples safety, but often the company seems to prefer rapidly developed features (which the company uses to make more money) over high quality code. The company likes to throw around the slogan that "our work helps protect people" to highlight the importance of our work, but their actions say "more features, more money, right now."
This isn't unique to the software development world as other professions have similar tradeoffs between work output, safety, and the time required to create the work.
What can be done as an individual contributor to ensure our work maximizes people's safety, despite the inevitable desire of companies to make more features and more money?
ethics safety
migrated from programmers.stackexchange.com Jan 11 '14 at 20:44
This question came from our site for professionals, academics, and students working within the systems development life cycle.
add a comment |Â
up vote
19
down vote
favorite
I work at a company where bugs in my code could affect peoples safety, but often the company seems to prefer rapidly developed features (which the company uses to make more money) over high quality code. The company likes to throw around the slogan that "our work helps protect people" to highlight the importance of our work, but their actions say "more features, more money, right now."
This isn't unique to the software development world as other professions have similar tradeoffs between work output, safety, and the time required to create the work.
What can be done as an individual contributor to ensure our work maximizes people's safety, despite the inevitable desire of companies to make more features and more money?
ethics safety
migrated from programmers.stackexchange.com Jan 11 '14 at 20:44
This question came from our site for professionals, academics, and students working within the systems development life cycle.
4
Does your company have a good insurance? ;-)
– Doc Brown
Jan 10 '14 at 21:57
2
Hi Buttons, I edited this question to make it a bit more generic to all industries. Let me know if this changes your intent too much, what you are asking here is not unique to the software industry and hopefully this will help you get more comprehensive and quality answers. Welcome to the Workplace!
– Elysian Fields♦
Jan 11 '14 at 20:57
add a comment |Â
up vote
19
down vote
favorite
up vote
19
down vote
favorite
I work at a company where bugs in my code could affect peoples safety, but often the company seems to prefer rapidly developed features (which the company uses to make more money) over high quality code. The company likes to throw around the slogan that "our work helps protect people" to highlight the importance of our work, but their actions say "more features, more money, right now."
This isn't unique to the software development world as other professions have similar tradeoffs between work output, safety, and the time required to create the work.
What can be done as an individual contributor to ensure our work maximizes people's safety, despite the inevitable desire of companies to make more features and more money?
ethics safety
I work at a company where bugs in my code could affect peoples safety, but often the company seems to prefer rapidly developed features (which the company uses to make more money) over high quality code. The company likes to throw around the slogan that "our work helps protect people" to highlight the importance of our work, but their actions say "more features, more money, right now."
This isn't unique to the software development world as other professions have similar tradeoffs between work output, safety, and the time required to create the work.
What can be done as an individual contributor to ensure our work maximizes people's safety, despite the inevitable desire of companies to make more features and more money?
ethics safety
edited Mar 31 '16 at 7:29


Jan Doggen
11.5k145066
11.5k145066
asked Jan 10 '14 at 20:43
Buttons840
224126
224126
migrated from programmers.stackexchange.com Jan 11 '14 at 20:44
This question came from our site for professionals, academics, and students working within the systems development life cycle.
migrated from programmers.stackexchange.com Jan 11 '14 at 20:44
This question came from our site for professionals, academics, and students working within the systems development life cycle.
4
Does your company have a good insurance? ;-)
– Doc Brown
Jan 10 '14 at 21:57
2
Hi Buttons, I edited this question to make it a bit more generic to all industries. Let me know if this changes your intent too much, what you are asking here is not unique to the software industry and hopefully this will help you get more comprehensive and quality answers. Welcome to the Workplace!
– Elysian Fields♦
Jan 11 '14 at 20:57
add a comment |Â
4
Does your company have a good insurance? ;-)
– Doc Brown
Jan 10 '14 at 21:57
2
Hi Buttons, I edited this question to make it a bit more generic to all industries. Let me know if this changes your intent too much, what you are asking here is not unique to the software industry and hopefully this will help you get more comprehensive and quality answers. Welcome to the Workplace!
– Elysian Fields♦
Jan 11 '14 at 20:57
4
4
Does your company have a good insurance? ;-)
– Doc Brown
Jan 10 '14 at 21:57
Does your company have a good insurance? ;-)
– Doc Brown
Jan 10 '14 at 21:57
2
2
Hi Buttons, I edited this question to make it a bit more generic to all industries. Let me know if this changes your intent too much, what you are asking here is not unique to the software industry and hopefully this will help you get more comprehensive and quality answers. Welcome to the Workplace!
– Elysian Fields♦
Jan 11 '14 at 20:57
Hi Buttons, I edited this question to make it a bit more generic to all industries. Let me know if this changes your intent too much, what you are asking here is not unique to the software industry and hopefully this will help you get more comprehensive and quality answers. Welcome to the Workplace!
– Elysian Fields♦
Jan 11 '14 at 20:57
add a comment |Â
4 Answers
4
active
oldest
votes
up vote
15
down vote
but their actions say "more features, more money, right now."
What actions, specifically?
I am not trying to disagree with you, but by understanding what actions are taken, we can better choose a reaction.
The quality versus timeliness debate is a problem that every software development house suffers.
There are 3 conflicting constraints you can overcome. Pick any 2:
- You can produce your product cheaply.
- You can produce your product at good quality.
- You can product your product quickly.
Every company thinks it can get all 3. It's a fantasy.
If you asked management which ones they value, would they admit to sacrificing the quality? It's possible to produce good quality software quickly. It just costs a lot because you'd have to hire extraordinarily good developers.
You, as a professional software engineer and somebody of high moral character, value quality in your work. That's great. Even if the company values getting features out quickly more than quality, you still have options.
Take Your Time
If management says you are working too slowly and they need to ship soon to get sales, explain that quality will suffer. If you have a release where you rushed and it had lots of problems and a release where you did not rush and had few or zero problems, cite that as justification.
If they point to a coworker and say "Jane is working faster than you", don't react. Do what you need to do to ensure your work meets your quality standards. If you cause fewer bugs than Jane, explain that to your manager (privately and politely. don't throw her under the bus. you should be defending yourself, not attacking Jane).
Budget for Quality
Programming very well takes time. When asked how long you need, give an honest estimate for how long you need to do a good job. Don't let management bully you into lowering your estimate. Then you will have to hurry and get sloppy to meet the stupidly-chosen deadline. Management should never tell you your estimate is wrong.
I've seen a co-worker get bullied by a manager (not his) for saying his project will take 3 months. A coworker stood up and said he can do it in a few hours. Projects led by that 1-hour coworker tend to launch many months late with thousands of open defects. The 3-month guy's project is finishing up on the exact day.
Break Projects into Smaller Projects
Sometimes, it isn't necessary to get everything shipped ASAP, but just to have quick turnarounds of something to show. If you work on features that take 3-6 months to build and are expected to do it in a month, would it help if you break the feature into several mini-feature releases so there is progress being shipped out the door quickly, but less risk to quality?
Show management examples of how poor quality can affect safety
As a developer, you probably don't get any communication or feedback to or from customers. So you don't know what safety issues they have experienced. However, you can theorize problems and talk management through it. Ask them how much it would cost to ensure these mistakes don't occur versus how much it would cost to handle litigation.
Go Work Somewhere Else
Ultimately, you work for your employer. You are there to help them achieve their goals. If their goals are in conflict with your values, you can find another job. I don't mean that to be insulting. Software engineers are very lucky to have tons of jobs available to choose from. Don't stay at a company that forces you to do something that could hurt people.
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
7
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
add a comment |Â
up vote
8
down vote
Licensed, professional software engineers are ethically required to place the public's safety at a higher priority than the needs of their employer.
If you were truly in a situation where the public's health or safety was jeopardized, you would be obligated to raise your concerns with your manager and on up through the rest of the company's hierarchy if you did not receive a satisfactory response that safeguarded the public. In the worst case, you would be obligated to continue your protests through to external, regulating bodies and potentially to the state board of professionals as a last resort. In the extreme case, you should quit your job and explain your concerns for the public safety as the basis for your resignation.
Have a look at the National Society of Professional Engineers Code of Ethics for Engineers or the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice
7
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
2
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
7
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
2
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
1
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
add a comment |Â
up vote
6
down vote
Executive Summary
There is no such thing as 100% safe. Nothing is infallible. The key is to balance the benefit of making something 99.99% safe vs. the additional cost over making it 99.9% safe. That is usually a decision for corporate officers and regulators. For someone working on the creation of that product, the goal should be to make it as safe as possible within the constraints given.
Disclaimer: The following is given on the premise that the company is not ignoring regulations, accepted safety standards, or somehow being deceitful about the actual safety of their product with knowledge otherwise.
Risk Management
Let's say I'm producing a product that has a defect rate of 0.01%. My customers will pay $10 more for a product with a defect rate of 0.001%. If it costs more than $10 to reduce the defect rate that much, it will actually make my customers more unhappy (as they won't value my product as highly due to the additional cost).
While distasteful, this math does extend to human safety as well. Let's say you are the owner of a trucking company. There is a truck on the market that will reduce mortality from accidents by a factor of 10, but it will increase your cost by $x per mile. If your customers aren't willing to pay the extra $x per mile, you have to make a business decision.
Safety does not exist in a vacuum, and nothing will be 100% safe. The tradeoff of increasing safety will hit a point where it is no longer possible to stay safe and remain in business.
Regulating Risk
This sort of risk calculus is the realm of corporate officers and regulators.
Some risks society dictates as "too big" and/or "too easy not to require", and regulate those risks through laws. For instance, seat belt laws, and safety standards for automobiles have been determined as "must-haves" and are regulated by the government. Prohibitions on smoking at gas pumps would be another example.
But beyond those regulated risks, it is up to corporate officers to decide what is right for their business. Let's say I own a construction firm. It is common knowledge that construction isn't the safest line of work (fatality rate of 10.8 per 100k employees in the US in 2006). Let's say you want me to build a house for you for $200k. How much are you willing to pay for the same house at a fatality rate of 8? 5? 2? How much will it cost for me to reduce fatality by that much? Alternatively, how much do I need to pay my workers for a fatality rate of 10.8 vs. 8, or 5, or 2?
If you aren't willing to pay as much as it costs for added safety, and/or my workers aren't willing to take a pay cut for the increased safety, then I won't be in the construction business long as I won't have customers or employees. This is my decision as a business owner to make. While this may sound distasteful, it is up to the market (both of employers, employees, and customers) to find the appropriate balance.
Safest Within Given Constraints
In general, your goal should be to:
- Identify the factors that have the biggest impact on safety
- Inform management about the relative risk of each of those factors
- Manage your work to maximize the safety given the constraints provided by your employer
Let's say you are a manager of a bunch of truck drivers. Management declined your suggestion to get the safer trucks because it is well beyond the budget that customers are willing to pay extra to for safety. You know that they won't pay the amount for the new trucks, but that doesn't mean they will totally ignore safety. You need to find a way to make truck driving as safe as possible given a limited budget.
Identify the Factors
Going through accident/incident logs for your employees, you identify the following major causes for accidents:
- Lack of sleep
- Inexperienced drivers
- Exceeding the speed limit
Inform Management
You compile statistics on those three factors, including the causes, and some potential solutions. For instance:
- Increasing staff to reduce extended periods on the road without rest
- Providing prepaid coffee cards to staff to ensure they can always be caffeinated when they are on the road long-term
- Hiring more experienced drivers by providing more competitive pay to them
- Providing driving instruction to new employees to minimize rookie mistakes
- Increasing driving times to minimize the incentive to speed
Work With What You're Given
So let's say the employer tells you that you have a budget of $X to try to tackle these issues. Your job is to make that budget of $X extend as far as possible to maximize the safety of your employees. You may not be able to do everything on your list, but that was a choice made by management that you can't do much about.
Part of working for other people is the need to compromise. It is their company, their money, and their rules. You can push to change them from within, but at the end of the day you have to work within the constraints given, or to quit. Realize that quitting will not solve the problem, it will just remove your responsibility for solving it.
add a comment |Â
up vote
3
down vote
One aspect not covered in the other good answers is perhaps your management really is considering safety. It is possible they have considered the issue of dangerous bugs, but consider that the software as is will still be safer than no software. Or releasing the software with some potential bugs will still save more lives than leaving it as it is until it is bug free.
If you are concerned about safety, it is worth going to your management and asking about it. Then listen. There are probably aspects that you haven't considered, that you may or may not agree with, but could be legitimate. Perhaps management is allowing technical debt or bugs for both business and safety reasons, not just immediate profit.
If you disagree, you're still able to consider fighting to lead for quality from the bottom, whistleblowing, or leaving. But you will also have more information for your ultimate decision.
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
15
down vote
but their actions say "more features, more money, right now."
What actions, specifically?
I am not trying to disagree with you, but by understanding what actions are taken, we can better choose a reaction.
The quality versus timeliness debate is a problem that every software development house suffers.
There are 3 conflicting constraints you can overcome. Pick any 2:
- You can produce your product cheaply.
- You can produce your product at good quality.
- You can product your product quickly.
Every company thinks it can get all 3. It's a fantasy.
If you asked management which ones they value, would they admit to sacrificing the quality? It's possible to produce good quality software quickly. It just costs a lot because you'd have to hire extraordinarily good developers.
You, as a professional software engineer and somebody of high moral character, value quality in your work. That's great. Even if the company values getting features out quickly more than quality, you still have options.
Take Your Time
If management says you are working too slowly and they need to ship soon to get sales, explain that quality will suffer. If you have a release where you rushed and it had lots of problems and a release where you did not rush and had few or zero problems, cite that as justification.
If they point to a coworker and say "Jane is working faster than you", don't react. Do what you need to do to ensure your work meets your quality standards. If you cause fewer bugs than Jane, explain that to your manager (privately and politely. don't throw her under the bus. you should be defending yourself, not attacking Jane).
Budget for Quality
Programming very well takes time. When asked how long you need, give an honest estimate for how long you need to do a good job. Don't let management bully you into lowering your estimate. Then you will have to hurry and get sloppy to meet the stupidly-chosen deadline. Management should never tell you your estimate is wrong.
I've seen a co-worker get bullied by a manager (not his) for saying his project will take 3 months. A coworker stood up and said he can do it in a few hours. Projects led by that 1-hour coworker tend to launch many months late with thousands of open defects. The 3-month guy's project is finishing up on the exact day.
Break Projects into Smaller Projects
Sometimes, it isn't necessary to get everything shipped ASAP, but just to have quick turnarounds of something to show. If you work on features that take 3-6 months to build and are expected to do it in a month, would it help if you break the feature into several mini-feature releases so there is progress being shipped out the door quickly, but less risk to quality?
Show management examples of how poor quality can affect safety
As a developer, you probably don't get any communication or feedback to or from customers. So you don't know what safety issues they have experienced. However, you can theorize problems and talk management through it. Ask them how much it would cost to ensure these mistakes don't occur versus how much it would cost to handle litigation.
Go Work Somewhere Else
Ultimately, you work for your employer. You are there to help them achieve their goals. If their goals are in conflict with your values, you can find another job. I don't mean that to be insulting. Software engineers are very lucky to have tons of jobs available to choose from. Don't stay at a company that forces you to do something that could hurt people.
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
7
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
add a comment |Â
up vote
15
down vote
but their actions say "more features, more money, right now."
What actions, specifically?
I am not trying to disagree with you, but by understanding what actions are taken, we can better choose a reaction.
The quality versus timeliness debate is a problem that every software development house suffers.
There are 3 conflicting constraints you can overcome. Pick any 2:
- You can produce your product cheaply.
- You can produce your product at good quality.
- You can product your product quickly.
Every company thinks it can get all 3. It's a fantasy.
If you asked management which ones they value, would they admit to sacrificing the quality? It's possible to produce good quality software quickly. It just costs a lot because you'd have to hire extraordinarily good developers.
You, as a professional software engineer and somebody of high moral character, value quality in your work. That's great. Even if the company values getting features out quickly more than quality, you still have options.
Take Your Time
If management says you are working too slowly and they need to ship soon to get sales, explain that quality will suffer. If you have a release where you rushed and it had lots of problems and a release where you did not rush and had few or zero problems, cite that as justification.
If they point to a coworker and say "Jane is working faster than you", don't react. Do what you need to do to ensure your work meets your quality standards. If you cause fewer bugs than Jane, explain that to your manager (privately and politely. don't throw her under the bus. you should be defending yourself, not attacking Jane).
Budget for Quality
Programming very well takes time. When asked how long you need, give an honest estimate for how long you need to do a good job. Don't let management bully you into lowering your estimate. Then you will have to hurry and get sloppy to meet the stupidly-chosen deadline. Management should never tell you your estimate is wrong.
I've seen a co-worker get bullied by a manager (not his) for saying his project will take 3 months. A coworker stood up and said he can do it in a few hours. Projects led by that 1-hour coworker tend to launch many months late with thousands of open defects. The 3-month guy's project is finishing up on the exact day.
Break Projects into Smaller Projects
Sometimes, it isn't necessary to get everything shipped ASAP, but just to have quick turnarounds of something to show. If you work on features that take 3-6 months to build and are expected to do it in a month, would it help if you break the feature into several mini-feature releases so there is progress being shipped out the door quickly, but less risk to quality?
Show management examples of how poor quality can affect safety
As a developer, you probably don't get any communication or feedback to or from customers. So you don't know what safety issues they have experienced. However, you can theorize problems and talk management through it. Ask them how much it would cost to ensure these mistakes don't occur versus how much it would cost to handle litigation.
Go Work Somewhere Else
Ultimately, you work for your employer. You are there to help them achieve their goals. If their goals are in conflict with your values, you can find another job. I don't mean that to be insulting. Software engineers are very lucky to have tons of jobs available to choose from. Don't stay at a company that forces you to do something that could hurt people.
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
7
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
add a comment |Â
up vote
15
down vote
up vote
15
down vote
but their actions say "more features, more money, right now."
What actions, specifically?
I am not trying to disagree with you, but by understanding what actions are taken, we can better choose a reaction.
The quality versus timeliness debate is a problem that every software development house suffers.
There are 3 conflicting constraints you can overcome. Pick any 2:
- You can produce your product cheaply.
- You can produce your product at good quality.
- You can product your product quickly.
Every company thinks it can get all 3. It's a fantasy.
If you asked management which ones they value, would they admit to sacrificing the quality? It's possible to produce good quality software quickly. It just costs a lot because you'd have to hire extraordinarily good developers.
You, as a professional software engineer and somebody of high moral character, value quality in your work. That's great. Even if the company values getting features out quickly more than quality, you still have options.
Take Your Time
If management says you are working too slowly and they need to ship soon to get sales, explain that quality will suffer. If you have a release where you rushed and it had lots of problems and a release where you did not rush and had few or zero problems, cite that as justification.
If they point to a coworker and say "Jane is working faster than you", don't react. Do what you need to do to ensure your work meets your quality standards. If you cause fewer bugs than Jane, explain that to your manager (privately and politely. don't throw her under the bus. you should be defending yourself, not attacking Jane).
Budget for Quality
Programming very well takes time. When asked how long you need, give an honest estimate for how long you need to do a good job. Don't let management bully you into lowering your estimate. Then you will have to hurry and get sloppy to meet the stupidly-chosen deadline. Management should never tell you your estimate is wrong.
I've seen a co-worker get bullied by a manager (not his) for saying his project will take 3 months. A coworker stood up and said he can do it in a few hours. Projects led by that 1-hour coworker tend to launch many months late with thousands of open defects. The 3-month guy's project is finishing up on the exact day.
Break Projects into Smaller Projects
Sometimes, it isn't necessary to get everything shipped ASAP, but just to have quick turnarounds of something to show. If you work on features that take 3-6 months to build and are expected to do it in a month, would it help if you break the feature into several mini-feature releases so there is progress being shipped out the door quickly, but less risk to quality?
Show management examples of how poor quality can affect safety
As a developer, you probably don't get any communication or feedback to or from customers. So you don't know what safety issues they have experienced. However, you can theorize problems and talk management through it. Ask them how much it would cost to ensure these mistakes don't occur versus how much it would cost to handle litigation.
Go Work Somewhere Else
Ultimately, you work for your employer. You are there to help them achieve their goals. If their goals are in conflict with your values, you can find another job. I don't mean that to be insulting. Software engineers are very lucky to have tons of jobs available to choose from. Don't stay at a company that forces you to do something that could hurt people.
but their actions say "more features, more money, right now."
What actions, specifically?
I am not trying to disagree with you, but by understanding what actions are taken, we can better choose a reaction.
The quality versus timeliness debate is a problem that every software development house suffers.
There are 3 conflicting constraints you can overcome. Pick any 2:
- You can produce your product cheaply.
- You can produce your product at good quality.
- You can product your product quickly.
Every company thinks it can get all 3. It's a fantasy.
If you asked management which ones they value, would they admit to sacrificing the quality? It's possible to produce good quality software quickly. It just costs a lot because you'd have to hire extraordinarily good developers.
You, as a professional software engineer and somebody of high moral character, value quality in your work. That's great. Even if the company values getting features out quickly more than quality, you still have options.
Take Your Time
If management says you are working too slowly and they need to ship soon to get sales, explain that quality will suffer. If you have a release where you rushed and it had lots of problems and a release where you did not rush and had few or zero problems, cite that as justification.
If they point to a coworker and say "Jane is working faster than you", don't react. Do what you need to do to ensure your work meets your quality standards. If you cause fewer bugs than Jane, explain that to your manager (privately and politely. don't throw her under the bus. you should be defending yourself, not attacking Jane).
Budget for Quality
Programming very well takes time. When asked how long you need, give an honest estimate for how long you need to do a good job. Don't let management bully you into lowering your estimate. Then you will have to hurry and get sloppy to meet the stupidly-chosen deadline. Management should never tell you your estimate is wrong.
I've seen a co-worker get bullied by a manager (not his) for saying his project will take 3 months. A coworker stood up and said he can do it in a few hours. Projects led by that 1-hour coworker tend to launch many months late with thousands of open defects. The 3-month guy's project is finishing up on the exact day.
Break Projects into Smaller Projects
Sometimes, it isn't necessary to get everything shipped ASAP, but just to have quick turnarounds of something to show. If you work on features that take 3-6 months to build and are expected to do it in a month, would it help if you break the feature into several mini-feature releases so there is progress being shipped out the door quickly, but less risk to quality?
Show management examples of how poor quality can affect safety
As a developer, you probably don't get any communication or feedback to or from customers. So you don't know what safety issues they have experienced. However, you can theorize problems and talk management through it. Ask them how much it would cost to ensure these mistakes don't occur versus how much it would cost to handle litigation.
Go Work Somewhere Else
Ultimately, you work for your employer. You are there to help them achieve their goals. If their goals are in conflict with your values, you can find another job. I don't mean that to be insulting. Software engineers are very lucky to have tons of jobs available to choose from. Don't stay at a company that forces you to do something that could hurt people.
answered Jan 10 '14 at 21:51
Brandon
50649
50649
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
7
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
add a comment |Â
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
7
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
I don't think it's a fantasy to think that you can have all 3. Quality code is actually faster to produce than sloppy code (consider the example of the 1 hour colleague). The trick is to not let the deadline pressure force you into making mistakes. You'll can't meet deadlines over more than a couple of releases if you sacrifice quality for short-term thinking. Trying to rush software just makes it take longer.
– Amy Blankenship
Jan 13 '14 at 20:33
7
7
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
You just proved the point. You sacrificed speed of development. Rushing does make it take longer due to mistakes. Because you sacrificed quality. Now to get that quality back, you have to spend time fixing the mistakes made by not doing it right the first time.
– Brandon
Jan 13 '14 at 20:45
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
Honestly, I'm not convinced you can get cheap and quick along with quality at all when it comes to software. Consider the, "Adding people makes a late software project later," adage. The "quick" is usually achieved by throwing more resources at a problem, but productivity doesn't scale linearly with people in software.
– jpmc26
May 18 at 17:59
add a comment |Â
up vote
8
down vote
Licensed, professional software engineers are ethically required to place the public's safety at a higher priority than the needs of their employer.
If you were truly in a situation where the public's health or safety was jeopardized, you would be obligated to raise your concerns with your manager and on up through the rest of the company's hierarchy if you did not receive a satisfactory response that safeguarded the public. In the worst case, you would be obligated to continue your protests through to external, regulating bodies and potentially to the state board of professionals as a last resort. In the extreme case, you should quit your job and explain your concerns for the public safety as the basis for your resignation.
Have a look at the National Society of Professional Engineers Code of Ethics for Engineers or the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice
7
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
2
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
7
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
2
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
1
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
add a comment |Â
up vote
8
down vote
Licensed, professional software engineers are ethically required to place the public's safety at a higher priority than the needs of their employer.
If you were truly in a situation where the public's health or safety was jeopardized, you would be obligated to raise your concerns with your manager and on up through the rest of the company's hierarchy if you did not receive a satisfactory response that safeguarded the public. In the worst case, you would be obligated to continue your protests through to external, regulating bodies and potentially to the state board of professionals as a last resort. In the extreme case, you should quit your job and explain your concerns for the public safety as the basis for your resignation.
Have a look at the National Society of Professional Engineers Code of Ethics for Engineers or the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice
7
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
2
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
7
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
2
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
1
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
add a comment |Â
up vote
8
down vote
up vote
8
down vote
Licensed, professional software engineers are ethically required to place the public's safety at a higher priority than the needs of their employer.
If you were truly in a situation where the public's health or safety was jeopardized, you would be obligated to raise your concerns with your manager and on up through the rest of the company's hierarchy if you did not receive a satisfactory response that safeguarded the public. In the worst case, you would be obligated to continue your protests through to external, regulating bodies and potentially to the state board of professionals as a last resort. In the extreme case, you should quit your job and explain your concerns for the public safety as the basis for your resignation.
Have a look at the National Society of Professional Engineers Code of Ethics for Engineers or the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice
Licensed, professional software engineers are ethically required to place the public's safety at a higher priority than the needs of their employer.
If you were truly in a situation where the public's health or safety was jeopardized, you would be obligated to raise your concerns with your manager and on up through the rest of the company's hierarchy if you did not receive a satisfactory response that safeguarded the public. In the worst case, you would be obligated to continue your protests through to external, regulating bodies and potentially to the state board of professionals as a last resort. In the extreme case, you should quit your job and explain your concerns for the public safety as the basis for your resignation.
Have a look at the National Society of Professional Engineers Code of Ethics for Engineers or the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice
answered Jan 10 '14 at 21:09


GlenH7
5341916
5341916
7
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
2
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
7
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
2
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
1
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
add a comment |Â
7
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
2
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
7
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
2
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
1
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
7
7
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
This answer is only applicable for the very narrow subset of “licensed software engineers†in the US. While the ethical obligation is universal, the global programmer community lacks an unifying credo, unlike the medical profession.
– amon
Jan 10 '14 at 21:19
2
2
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
If you want to cite a code of conduct, I believe the IEEE and ACM's Software Engineering Code of Ethics and Professional Practice may be more relevant and widely applicable.
– Thomas Owens
Jan 10 '14 at 21:24
7
7
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
@amon - To an extent, I disagree with you regarding the applicability of my answer. The ethical obligation is equivalent regardless of licensure. If you see a real, valid problem (which the OP states they do not have), then you raise the issue with management. You continue that process all the way "up the chain" until you get a satisfactory answer or the chain runs out. The only difference I see is that a licensed software PE may face sanctions for failing to follow that ethical obligation.
– GlenH7
Jan 10 '14 at 21:24
2
2
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
Software has an engineering license? Is there an exam and what authority handles this?
– user8365
Jan 10 '14 at 23:35
1
1
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
@JeffO - related press release: ncees.org/about-ncees/news/…
– GlenH7
Jan 11 '14 at 0:13
add a comment |Â
up vote
6
down vote
Executive Summary
There is no such thing as 100% safe. Nothing is infallible. The key is to balance the benefit of making something 99.99% safe vs. the additional cost over making it 99.9% safe. That is usually a decision for corporate officers and regulators. For someone working on the creation of that product, the goal should be to make it as safe as possible within the constraints given.
Disclaimer: The following is given on the premise that the company is not ignoring regulations, accepted safety standards, or somehow being deceitful about the actual safety of their product with knowledge otherwise.
Risk Management
Let's say I'm producing a product that has a defect rate of 0.01%. My customers will pay $10 more for a product with a defect rate of 0.001%. If it costs more than $10 to reduce the defect rate that much, it will actually make my customers more unhappy (as they won't value my product as highly due to the additional cost).
While distasteful, this math does extend to human safety as well. Let's say you are the owner of a trucking company. There is a truck on the market that will reduce mortality from accidents by a factor of 10, but it will increase your cost by $x per mile. If your customers aren't willing to pay the extra $x per mile, you have to make a business decision.
Safety does not exist in a vacuum, and nothing will be 100% safe. The tradeoff of increasing safety will hit a point where it is no longer possible to stay safe and remain in business.
Regulating Risk
This sort of risk calculus is the realm of corporate officers and regulators.
Some risks society dictates as "too big" and/or "too easy not to require", and regulate those risks through laws. For instance, seat belt laws, and safety standards for automobiles have been determined as "must-haves" and are regulated by the government. Prohibitions on smoking at gas pumps would be another example.
But beyond those regulated risks, it is up to corporate officers to decide what is right for their business. Let's say I own a construction firm. It is common knowledge that construction isn't the safest line of work (fatality rate of 10.8 per 100k employees in the US in 2006). Let's say you want me to build a house for you for $200k. How much are you willing to pay for the same house at a fatality rate of 8? 5? 2? How much will it cost for me to reduce fatality by that much? Alternatively, how much do I need to pay my workers for a fatality rate of 10.8 vs. 8, or 5, or 2?
If you aren't willing to pay as much as it costs for added safety, and/or my workers aren't willing to take a pay cut for the increased safety, then I won't be in the construction business long as I won't have customers or employees. This is my decision as a business owner to make. While this may sound distasteful, it is up to the market (both of employers, employees, and customers) to find the appropriate balance.
Safest Within Given Constraints
In general, your goal should be to:
- Identify the factors that have the biggest impact on safety
- Inform management about the relative risk of each of those factors
- Manage your work to maximize the safety given the constraints provided by your employer
Let's say you are a manager of a bunch of truck drivers. Management declined your suggestion to get the safer trucks because it is well beyond the budget that customers are willing to pay extra to for safety. You know that they won't pay the amount for the new trucks, but that doesn't mean they will totally ignore safety. You need to find a way to make truck driving as safe as possible given a limited budget.
Identify the Factors
Going through accident/incident logs for your employees, you identify the following major causes for accidents:
- Lack of sleep
- Inexperienced drivers
- Exceeding the speed limit
Inform Management
You compile statistics on those three factors, including the causes, and some potential solutions. For instance:
- Increasing staff to reduce extended periods on the road without rest
- Providing prepaid coffee cards to staff to ensure they can always be caffeinated when they are on the road long-term
- Hiring more experienced drivers by providing more competitive pay to them
- Providing driving instruction to new employees to minimize rookie mistakes
- Increasing driving times to minimize the incentive to speed
Work With What You're Given
So let's say the employer tells you that you have a budget of $X to try to tackle these issues. Your job is to make that budget of $X extend as far as possible to maximize the safety of your employees. You may not be able to do everything on your list, but that was a choice made by management that you can't do much about.
Part of working for other people is the need to compromise. It is their company, their money, and their rules. You can push to change them from within, but at the end of the day you have to work within the constraints given, or to quit. Realize that quitting will not solve the problem, it will just remove your responsibility for solving it.
add a comment |Â
up vote
6
down vote
Executive Summary
There is no such thing as 100% safe. Nothing is infallible. The key is to balance the benefit of making something 99.99% safe vs. the additional cost over making it 99.9% safe. That is usually a decision for corporate officers and regulators. For someone working on the creation of that product, the goal should be to make it as safe as possible within the constraints given.
Disclaimer: The following is given on the premise that the company is not ignoring regulations, accepted safety standards, or somehow being deceitful about the actual safety of their product with knowledge otherwise.
Risk Management
Let's say I'm producing a product that has a defect rate of 0.01%. My customers will pay $10 more for a product with a defect rate of 0.001%. If it costs more than $10 to reduce the defect rate that much, it will actually make my customers more unhappy (as they won't value my product as highly due to the additional cost).
While distasteful, this math does extend to human safety as well. Let's say you are the owner of a trucking company. There is a truck on the market that will reduce mortality from accidents by a factor of 10, but it will increase your cost by $x per mile. If your customers aren't willing to pay the extra $x per mile, you have to make a business decision.
Safety does not exist in a vacuum, and nothing will be 100% safe. The tradeoff of increasing safety will hit a point where it is no longer possible to stay safe and remain in business.
Regulating Risk
This sort of risk calculus is the realm of corporate officers and regulators.
Some risks society dictates as "too big" and/or "too easy not to require", and regulate those risks through laws. For instance, seat belt laws, and safety standards for automobiles have been determined as "must-haves" and are regulated by the government. Prohibitions on smoking at gas pumps would be another example.
But beyond those regulated risks, it is up to corporate officers to decide what is right for their business. Let's say I own a construction firm. It is common knowledge that construction isn't the safest line of work (fatality rate of 10.8 per 100k employees in the US in 2006). Let's say you want me to build a house for you for $200k. How much are you willing to pay for the same house at a fatality rate of 8? 5? 2? How much will it cost for me to reduce fatality by that much? Alternatively, how much do I need to pay my workers for a fatality rate of 10.8 vs. 8, or 5, or 2?
If you aren't willing to pay as much as it costs for added safety, and/or my workers aren't willing to take a pay cut for the increased safety, then I won't be in the construction business long as I won't have customers or employees. This is my decision as a business owner to make. While this may sound distasteful, it is up to the market (both of employers, employees, and customers) to find the appropriate balance.
Safest Within Given Constraints
In general, your goal should be to:
- Identify the factors that have the biggest impact on safety
- Inform management about the relative risk of each of those factors
- Manage your work to maximize the safety given the constraints provided by your employer
Let's say you are a manager of a bunch of truck drivers. Management declined your suggestion to get the safer trucks because it is well beyond the budget that customers are willing to pay extra to for safety. You know that they won't pay the amount for the new trucks, but that doesn't mean they will totally ignore safety. You need to find a way to make truck driving as safe as possible given a limited budget.
Identify the Factors
Going through accident/incident logs for your employees, you identify the following major causes for accidents:
- Lack of sleep
- Inexperienced drivers
- Exceeding the speed limit
Inform Management
You compile statistics on those three factors, including the causes, and some potential solutions. For instance:
- Increasing staff to reduce extended periods on the road without rest
- Providing prepaid coffee cards to staff to ensure they can always be caffeinated when they are on the road long-term
- Hiring more experienced drivers by providing more competitive pay to them
- Providing driving instruction to new employees to minimize rookie mistakes
- Increasing driving times to minimize the incentive to speed
Work With What You're Given
So let's say the employer tells you that you have a budget of $X to try to tackle these issues. Your job is to make that budget of $X extend as far as possible to maximize the safety of your employees. You may not be able to do everything on your list, but that was a choice made by management that you can't do much about.
Part of working for other people is the need to compromise. It is their company, their money, and their rules. You can push to change them from within, but at the end of the day you have to work within the constraints given, or to quit. Realize that quitting will not solve the problem, it will just remove your responsibility for solving it.
add a comment |Â
up vote
6
down vote
up vote
6
down vote
Executive Summary
There is no such thing as 100% safe. Nothing is infallible. The key is to balance the benefit of making something 99.99% safe vs. the additional cost over making it 99.9% safe. That is usually a decision for corporate officers and regulators. For someone working on the creation of that product, the goal should be to make it as safe as possible within the constraints given.
Disclaimer: The following is given on the premise that the company is not ignoring regulations, accepted safety standards, or somehow being deceitful about the actual safety of their product with knowledge otherwise.
Risk Management
Let's say I'm producing a product that has a defect rate of 0.01%. My customers will pay $10 more for a product with a defect rate of 0.001%. If it costs more than $10 to reduce the defect rate that much, it will actually make my customers more unhappy (as they won't value my product as highly due to the additional cost).
While distasteful, this math does extend to human safety as well. Let's say you are the owner of a trucking company. There is a truck on the market that will reduce mortality from accidents by a factor of 10, but it will increase your cost by $x per mile. If your customers aren't willing to pay the extra $x per mile, you have to make a business decision.
Safety does not exist in a vacuum, and nothing will be 100% safe. The tradeoff of increasing safety will hit a point where it is no longer possible to stay safe and remain in business.
Regulating Risk
This sort of risk calculus is the realm of corporate officers and regulators.
Some risks society dictates as "too big" and/or "too easy not to require", and regulate those risks through laws. For instance, seat belt laws, and safety standards for automobiles have been determined as "must-haves" and are regulated by the government. Prohibitions on smoking at gas pumps would be another example.
But beyond those regulated risks, it is up to corporate officers to decide what is right for their business. Let's say I own a construction firm. It is common knowledge that construction isn't the safest line of work (fatality rate of 10.8 per 100k employees in the US in 2006). Let's say you want me to build a house for you for $200k. How much are you willing to pay for the same house at a fatality rate of 8? 5? 2? How much will it cost for me to reduce fatality by that much? Alternatively, how much do I need to pay my workers for a fatality rate of 10.8 vs. 8, or 5, or 2?
If you aren't willing to pay as much as it costs for added safety, and/or my workers aren't willing to take a pay cut for the increased safety, then I won't be in the construction business long as I won't have customers or employees. This is my decision as a business owner to make. While this may sound distasteful, it is up to the market (both of employers, employees, and customers) to find the appropriate balance.
Safest Within Given Constraints
In general, your goal should be to:
- Identify the factors that have the biggest impact on safety
- Inform management about the relative risk of each of those factors
- Manage your work to maximize the safety given the constraints provided by your employer
Let's say you are a manager of a bunch of truck drivers. Management declined your suggestion to get the safer trucks because it is well beyond the budget that customers are willing to pay extra to for safety. You know that they won't pay the amount for the new trucks, but that doesn't mean they will totally ignore safety. You need to find a way to make truck driving as safe as possible given a limited budget.
Identify the Factors
Going through accident/incident logs for your employees, you identify the following major causes for accidents:
- Lack of sleep
- Inexperienced drivers
- Exceeding the speed limit
Inform Management
You compile statistics on those three factors, including the causes, and some potential solutions. For instance:
- Increasing staff to reduce extended periods on the road without rest
- Providing prepaid coffee cards to staff to ensure they can always be caffeinated when they are on the road long-term
- Hiring more experienced drivers by providing more competitive pay to them
- Providing driving instruction to new employees to minimize rookie mistakes
- Increasing driving times to minimize the incentive to speed
Work With What You're Given
So let's say the employer tells you that you have a budget of $X to try to tackle these issues. Your job is to make that budget of $X extend as far as possible to maximize the safety of your employees. You may not be able to do everything on your list, but that was a choice made by management that you can't do much about.
Part of working for other people is the need to compromise. It is their company, their money, and their rules. You can push to change them from within, but at the end of the day you have to work within the constraints given, or to quit. Realize that quitting will not solve the problem, it will just remove your responsibility for solving it.
Executive Summary
There is no such thing as 100% safe. Nothing is infallible. The key is to balance the benefit of making something 99.99% safe vs. the additional cost over making it 99.9% safe. That is usually a decision for corporate officers and regulators. For someone working on the creation of that product, the goal should be to make it as safe as possible within the constraints given.
Disclaimer: The following is given on the premise that the company is not ignoring regulations, accepted safety standards, or somehow being deceitful about the actual safety of their product with knowledge otherwise.
Risk Management
Let's say I'm producing a product that has a defect rate of 0.01%. My customers will pay $10 more for a product with a defect rate of 0.001%. If it costs more than $10 to reduce the defect rate that much, it will actually make my customers more unhappy (as they won't value my product as highly due to the additional cost).
While distasteful, this math does extend to human safety as well. Let's say you are the owner of a trucking company. There is a truck on the market that will reduce mortality from accidents by a factor of 10, but it will increase your cost by $x per mile. If your customers aren't willing to pay the extra $x per mile, you have to make a business decision.
Safety does not exist in a vacuum, and nothing will be 100% safe. The tradeoff of increasing safety will hit a point where it is no longer possible to stay safe and remain in business.
Regulating Risk
This sort of risk calculus is the realm of corporate officers and regulators.
Some risks society dictates as "too big" and/or "too easy not to require", and regulate those risks through laws. For instance, seat belt laws, and safety standards for automobiles have been determined as "must-haves" and are regulated by the government. Prohibitions on smoking at gas pumps would be another example.
But beyond those regulated risks, it is up to corporate officers to decide what is right for their business. Let's say I own a construction firm. It is common knowledge that construction isn't the safest line of work (fatality rate of 10.8 per 100k employees in the US in 2006). Let's say you want me to build a house for you for $200k. How much are you willing to pay for the same house at a fatality rate of 8? 5? 2? How much will it cost for me to reduce fatality by that much? Alternatively, how much do I need to pay my workers for a fatality rate of 10.8 vs. 8, or 5, or 2?
If you aren't willing to pay as much as it costs for added safety, and/or my workers aren't willing to take a pay cut for the increased safety, then I won't be in the construction business long as I won't have customers or employees. This is my decision as a business owner to make. While this may sound distasteful, it is up to the market (both of employers, employees, and customers) to find the appropriate balance.
Safest Within Given Constraints
In general, your goal should be to:
- Identify the factors that have the biggest impact on safety
- Inform management about the relative risk of each of those factors
- Manage your work to maximize the safety given the constraints provided by your employer
Let's say you are a manager of a bunch of truck drivers. Management declined your suggestion to get the safer trucks because it is well beyond the budget that customers are willing to pay extra to for safety. You know that they won't pay the amount for the new trucks, but that doesn't mean they will totally ignore safety. You need to find a way to make truck driving as safe as possible given a limited budget.
Identify the Factors
Going through accident/incident logs for your employees, you identify the following major causes for accidents:
- Lack of sleep
- Inexperienced drivers
- Exceeding the speed limit
Inform Management
You compile statistics on those three factors, including the causes, and some potential solutions. For instance:
- Increasing staff to reduce extended periods on the road without rest
- Providing prepaid coffee cards to staff to ensure they can always be caffeinated when they are on the road long-term
- Hiring more experienced drivers by providing more competitive pay to them
- Providing driving instruction to new employees to minimize rookie mistakes
- Increasing driving times to minimize the incentive to speed
Work With What You're Given
So let's say the employer tells you that you have a budget of $X to try to tackle these issues. Your job is to make that budget of $X extend as far as possible to maximize the safety of your employees. You may not be able to do everything on your list, but that was a choice made by management that you can't do much about.
Part of working for other people is the need to compromise. It is their company, their money, and their rules. You can push to change them from within, but at the end of the day you have to work within the constraints given, or to quit. Realize that quitting will not solve the problem, it will just remove your responsibility for solving it.
answered Jan 14 '14 at 2:00


jmac
19.4k763137
19.4k763137
add a comment |Â
add a comment |Â
up vote
3
down vote
One aspect not covered in the other good answers is perhaps your management really is considering safety. It is possible they have considered the issue of dangerous bugs, but consider that the software as is will still be safer than no software. Or releasing the software with some potential bugs will still save more lives than leaving it as it is until it is bug free.
If you are concerned about safety, it is worth going to your management and asking about it. Then listen. There are probably aspects that you haven't considered, that you may or may not agree with, but could be legitimate. Perhaps management is allowing technical debt or bugs for both business and safety reasons, not just immediate profit.
If you disagree, you're still able to consider fighting to lead for quality from the bottom, whistleblowing, or leaving. But you will also have more information for your ultimate decision.
add a comment |Â
up vote
3
down vote
One aspect not covered in the other good answers is perhaps your management really is considering safety. It is possible they have considered the issue of dangerous bugs, but consider that the software as is will still be safer than no software. Or releasing the software with some potential bugs will still save more lives than leaving it as it is until it is bug free.
If you are concerned about safety, it is worth going to your management and asking about it. Then listen. There are probably aspects that you haven't considered, that you may or may not agree with, but could be legitimate. Perhaps management is allowing technical debt or bugs for both business and safety reasons, not just immediate profit.
If you disagree, you're still able to consider fighting to lead for quality from the bottom, whistleblowing, or leaving. But you will also have more information for your ultimate decision.
add a comment |Â
up vote
3
down vote
up vote
3
down vote
One aspect not covered in the other good answers is perhaps your management really is considering safety. It is possible they have considered the issue of dangerous bugs, but consider that the software as is will still be safer than no software. Or releasing the software with some potential bugs will still save more lives than leaving it as it is until it is bug free.
If you are concerned about safety, it is worth going to your management and asking about it. Then listen. There are probably aspects that you haven't considered, that you may or may not agree with, but could be legitimate. Perhaps management is allowing technical debt or bugs for both business and safety reasons, not just immediate profit.
If you disagree, you're still able to consider fighting to lead for quality from the bottom, whistleblowing, or leaving. But you will also have more information for your ultimate decision.
One aspect not covered in the other good answers is perhaps your management really is considering safety. It is possible they have considered the issue of dangerous bugs, but consider that the software as is will still be safer than no software. Or releasing the software with some potential bugs will still save more lives than leaving it as it is until it is bug free.
If you are concerned about safety, it is worth going to your management and asking about it. Then listen. There are probably aspects that you haven't considered, that you may or may not agree with, but could be legitimate. Perhaps management is allowing technical debt or bugs for both business and safety reasons, not just immediate profit.
If you disagree, you're still able to consider fighting to lead for quality from the bottom, whistleblowing, or leaving. But you will also have more information for your ultimate decision.
answered Jan 13 '14 at 18:39
thursdaysgeek
24.2k103998
24.2k103998
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f17987%2fmy-work-can-affect-peoples-safety-and-my-employer-prefers-rapid-development-ove%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
4
Does your company have a good insurance? ;-)
– Doc Brown
Jan 10 '14 at 21:57
2
Hi Buttons, I edited this question to make it a bit more generic to all industries. Let me know if this changes your intent too much, what you are asking here is not unique to the software industry and hopefully this will help you get more comprehensive and quality answers. Welcome to the Workplace!
– Elysian Fields♦
Jan 11 '14 at 20:57