Skip over menu

Software Safety Home Page
Metrics Gone Bad
Last Modified on: Fri Sep 26 20:15:09 2008
Navigation Menu Left:

Books to read
Compliers with safety in mind
Esterel.org Reactive Programing Language
Guidelines for better software
Hardware Design Tips
ISO9000, the correct meaning
Internationalization (I18N & L10)
Jobs

'If you cannot MEASURE it, you cannot IMPROVE it'.
- Lord Kelvin, IEC's first President (1906).

Navigation Menu Right:

Metrics Gone Bad
Metrics
Past Visitors
Photosensitive Epilepsy
Quality
Software Patents Gone Bad
Tools
Translate the Software Safety web site




If you think that I could be of some assistance to you or your organization let me know,
American Society for Quality  Certified Software Quality Engineer.

Software Safety now has a blog! Check it out.

This site has been listed as the EG3 Editor's Choice in the Embedded Safety category for February 2004.

eCLIPS gives this site four of five stars in the September 7th 2004 SAFETY CRITICAL - DESIGN GUIDE.


PicoSearch
  Help
Site Search by PicoSearch 
Text Search



Myth of Sisyphus pushing stone forever up hill

There is a way out of our Software/System Safety Crisis.

It starts with you reading Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Press, 1982,.   Deming's 14 points for the transformation of management, must be at the top of your reading list, if you want to have the best company that you can create.

The Deming Chain Reaction:

These are the possible results obtained when Deming's 14 Points are properly applied in an organization (Crawford, 1992):

Excript from Memo To The Boss by Jack Ganssle .
"W. Edwards Deming, the great quality guru, long ago examined factors influencing motivation. [1] He found professionals get most of their drive from "intrinsic" motivating factors, those that come from within ourselves. Things like feeling part of the team. The desire for the organization's success. Wanting to deliver a great product. Intolerance of poor quality.

He described "extrinsic" motivators as those imposed from on-high, usually without any sort of buy-in from the professionals involved. Artificial measurements [pie charts on the wall] ranked high on his list of extrinsic motivators. Deming showed that extrinsic motivators invariably drive out the intrinsic ones. In other words, people shrug in frustration and work to meet the numbers, rather than try to make things right. A prime example: your imposition of lines-of-code-per-day metrics. You wanted lots and lots of software, and we gave it to you. Oh man, did we crank code! Most of it sucked, of course, and the resulting clean-up is still incomplete."

[1] Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Press, 1982.

The following is a list of motivation zapping organizational behaviors that will demotivate your employees:


If you want to have the best software orginzation that your money can buy then it is imparitive that you do not let the Bean Counters be in control.   Cutting costs and analyzing productivity may look great on paper, but the effect on a company's long-term competitiveness can be devastating.


To measure your staff's productivity is not the same as to improve it; "What you measure wrong, you manage wrong." - Bob Lewis in InfoWorld. ... Which can also be read as "Management tends to measure the things that are easy to measure, and ignore the things that are hard to measure."

(1) List every variable that can affect a system.
(2) Study every variable that is easy to measure.
(3) Declare these to be the only important variables affecting the system.
(4) Proclaim that the other variables do not really exist.

In establishing quality and performance measures, many managers follow a similar sequence. They end up measuring what's convenient, not what's important.


It is important for you to understand the Hawthorne Effect: if people know they're being measured, they alter their behavior to optimize the measurement.

The name "Hawthorne Effect" comes from some early work (1927-1932) on organizational measurement done at the Western Electric plant in Hawthorne, Illinois. The management tried to determine optimum levels of factory-floor lighting. The employees knew about the study, so they responded to each adjustment in light level by increasing productivity.

The Hawthorne Effect applies to software: In one approach to controlling software quality, we measure defects by severity category. Since software is not releasable unless defect counts are below acceptable levels, there is pressure to downgrade the severity of any defects in categories that are over threshold.


Parkinson's First Law:

Work expands to fill time available for its completion; the thing to be done swells in perceived importance and complexity in a direct ratio with the time to be spent in its completion.

Some thing from Extreme Programming (XP):

40-hour Week: Tired programmers make more mistakes. Programing teams do not work excessive overtime, keeping themselves fresh, healthy, and effective.

The Work harder, not smarter philosophy doesn't really add anything to productivity.

A lot of engineers work overtime because they (and their bosses) do not continuously monitor the amount of work left to do on a project before the next deadline looms.

You have to help manage expectations and avoid schedule problems.

Overworked people make mistakes, and companies that juggle too many projects risk destroying their credibility with their customers.

Bosses can be totally wrong, deadlines totally unrealistic. Yet most employees feel compelled to sign on to unreasonable schedules. No item appears on the schedule if the person who has to execute it hasn't bought into it.

60-hour-week engineering teams routinely say "yes" to any amount of work to be done by any deadline. (What's one more concurrent deadline, when you've already got too many?) Such teams tend to work furiously until they realize, "Ooops! We're not going to make it!" At that point, rather than adapt expectations to match reality, the company imposes even more mandatory overtime so they can make the unrealistic deadline. Such deadlines are often not met, quality suffers and morale declines -- but everyone's a hero because they tried so hard. The net result? Everyone's confidence in their own work and in the system that produced it goes to pot.

The long view of the productivity curve.

"I'd like to make a comment about the common assumption that extra hours worked equals extra productivity. It's true only up to a point, then it's totally false. In a short burst of overtime (days to a week or two), it is likely that most workers will get more done than if they had worked only 40 hours. In a long bout of overtime, (months), as fatigue mounts, carelessness increases while concentration and creativity decrease. Taken to extremes this can lead to an increase in illness and increased likelihood of family problems such as divorce. None of this is good for productivity over the long run."



Select from the menu other areas of Software Safety that you would like to explore.


If you think that I could be of some assistance to you or your organization let me know,
American Society for Quality  Certified Software Quality Engineer.




Go Back To The  Software Safety Home Page