Programmer's Toolbox
Comment
eembedded_janitor
CMM looks down on heroes because reliance on heros is an inherently ...
MikeLC
Patrick, I really liked your comments. Well said!
More about mediocrity
Jack Crenshaw
8/23/2010 11:34 PM EDT
Do you get the impression from my previous column that I’m not a big fan of mediocrity? You’re right.
I’m old enough to remember the days when there were no such things as franchise motels. Your average “motel” was more likely to be a collection of little cottages, much like an RV park of today. You paid your money, you got to sleep in one of the cottages, and the term “quality” was interpreted as, no roaches crawling across your nose. Maid service? Surely you jest.
Then along came the Interstate Highways. And with the highways, this wonderful franchise known as the Holiday Inn. It was a great relief to us travelers, and my family and I used them with gratitude.
Over time, though, other competing motels came along, and as our standards for excellence got more stringent, the Holiday Inns didn’t seem as appealing as before.
Other travelers still love the Holiday Inns, though, and I think I’ve figured out why. Holiday Inn doesn’t pretend to offer luxury.
What they offer is a uniform level of mediocrity. It’s not luxurious, but it’s not bad, either. Staying there, you won’t feel coddled in the lap of luxury, but you won’t find that proverbial roach on your nose, either.
My son used to play youth hockey, and he was very good at it. Each year, the sponsoring YMCA held its annual banquet. Each year, the coaches would nominate outstanding players to be selected for the All-Star team. Each selected kid got a huge trophy and a nice jacket with a big ‘Y’ on it. It was a matter of considerable pride.
One year, the ‘Y” announced that there would be no more all-star awards. Some of the parents, it seems, were complaining. Their son, little Johnny, hadn’t been selected, and it bwoke his widdle heart. So rather than disappointed little Johnny, the Y decided to kill the All-Star program completely, thereby disappointing EVERYBODY.
In our city, we told the Y to get stuffed, formed our own hockey association, and continued right on with the All-Star program. Even so, the pressure from disappointed parents has continued unabated, and my son – now a coach – is continually frustrated by the attitude that excellence doesn’t matter. Hey, the parents argue, it’s just a game. And who cares if we win or lose?
It’s this attitude that has all kids getting “participation trophies,” and school kids getting grades like “acceptable” rather than numeric scores. Or, better yet, no scores at all. If your doctor graduated from Harvard Medical School, do you feel better knowing that he earned a grade of “pass”? Hey, at least he wasn’t stressed, and had better group cohesion. Isn’t that special?
I call this trend “The Glorification of Mediocrity.” Moreover, I detest it, as much when it’s related to software, as when it’s related to hockey or Harvard.
The SEI and CMMBy far the most successful efforts to deal with the Software Crisis came from Carnegie Mellon’s Software Engineering Institute (SEI). Over time, SEI developed a method for evaluating the maturity of an organization’s software process. They further developed a classification system, which evolved into the SEI Capability Maturity Model (CMM). The model defines five levels of software maturity, ranging from Level 1 (Initial – you get this for being alive) to Level 5 (Optimizing).
See more about all of this at http://en.wikipedia.org/wiki/Capability_Maturity_Model
At this point, DoD and most other organizations require all contractors to have CMM Level 3 or better. You get an SEI rating by scheduling an evaluation. An SEI evaluation team will come in, ask questions, review the organizations established processes, and interview people from top management down to the individual developers. Based on their findings, you get an SEI rating.
Quality revisitedSeveral years ago, my company was going through the “quality circle” fad. They got so into the idea that they decided to vie for an annual award for corporate emphasis on quality. The management presented a questionnaire to all the project leaders, which included the following question:
“Do you even feel that the quality of your product has ever been comprimized by production schedules or budget limitations?”
A colleague answered, “Of course. It happens every day. Every day, I have to make decisions based on time and budget constraints, and the decisions often impact quality.”
There was a long silence, following which, one of the Vice Presidents patiently explained, “See, John, the problem is that you don’t understand the Ajax definition of quality.”
He went on to explain that, in the Ajax Corporation, quality should extend only to that required by the contract. In other words, the product was a quality product if it passed the customer’s acceptance tests, without getting us disqualified as nonresponsive.
Anything more than that, said the VP, was a waste of company profits.
I need a heroI recently worked for a company called Spectrum Astro, Inc. We made satellites, including the software that went into their flight computers. I couldn’t help but notice that previous software products seemed to have an exceptional record for quality, with no schedule slips or cost overruns.
I asked my boss, “In the history of the company, has their ever been a case of our software failing in orbit?”
He replied, “Not one.”
How do you produce software like that? I can tell you, it’s not by giving pass/fail grades.
I asked another colleague how they had done it. He said, “We had heroes.”
He went on to explain that, while the flight software group had many people with the usual distribution of talents, they also had a handful of heroes; people who combined incredibly good technical skills with hard work, and a willingness to work ridiculous schedules and pull miracles out of the hat, to get the job done on schedule. The teams were small enough so that one hero could make a big difference, in both group attitudes and delivered results.
SEI vs HeroesShortly after I arrived at Spectrum Astro, we sought to establish a Software Engineering Institute (SEI) rating of Level 3. We got it. As part of the process, folks came in to give us tutorials on how to earn, keep, and improve our rating, and how to follow the CMM guidelines.
The course was great, but I was dismayed to hear the SEI view of heroes. They didn’t like them. At all. The presenter, in fact, had some rather nasty things to say about heroes. This surprised me.
In retrospect, I think I think I understand what they mean by the term, “Hero.” It’s not the same thing I mean, or what my colleague meant. SEI apparently uses the term synonymously with “wizard” or “hacker.” If that’s the case, we agree. I, too, am quick to show wizards to the door. Fortunately, wizards are easy to deal with. They have inordantly high evaluations of themselves, so they like the title, wizard. You ask the prospective hire, “Are you a wizard?” If he says yes, don’t hire him.
But the folks who worked long hours to bring in all those projects on time, on budget, and error free, were the antitheses of wizards. They were highly accomplished, professional and experienced engineers, who knew what had to be done to meet their commitments, and did it. They were, in fact, master craftsmen.
I’m concerned that SEI’s attitude concerning heroes is just another example of the Glorification of Mediocrity.
Is software quality not something to be desired? Are we willing to settle for mediocrity, just to get the right evaluation or get a system to completion on schedule? Maybe so, but I still find it depressing.
But I think that you don’t get superior quality from mediocre people following mediocre processes. You’re going to need creative, inventive, and capable people, willing to go that extra distance to achieve excellence. You’re going to need artisans. You’re going to need heroes.
(Jack Crenshaw is a systems engineer and the author of Math Toolkit for Real-Time Programming. He holds a PhD in physics from Auburn University. E-mail him at jcrens@earthlink.net. For more information about Jack click here)
|
|
|
|
|
Test_engineer
8/24/2010 10:51 AM EDT
In my job as a test engineer, I constantly see the end result of people not going that extra mile: poor design, poor technical communications. You offer somebody a suggestion; and, what do you get from that person in return? An attitude.
To be very honest,Jack,I'm looking at entering a new career where I don't have to deal with idiots with their Blackberrys on a daily basis. I've been doing this type of work too long. Have a nice day.
Sign in to Reply
antiquus
8/24/2010 4:06 PM EDT
Often the "hero" is overshadowed by the overachiever: this is the guy that has to always be right, and has to provide the solution for every problem. AT a previous employer, there was a guy that would attack the top problem until a solution was discovered, sometimes shouldering aside those that should have been responsible, but more often being thrust ahead of his colleagues by impatient management. He was incapable of documenting the solution in detail (relying on the responsible engineer to clean up), and could not be burdened with addressing the process issues that led to the problem in the first place. However, he usually got the attention and praise of management for being so "smart and dedicated", and responding with his full attention.
In my mind, the heroes were the guys (occasionally me, most often not), that held fast to the loose ends of the process threads so that the solution could be communicated to manufacturing and the customer.
Sign in to Reply
lwriemen
8/26/2010 10:55 AM EDT
It's OK to work long hours to bring a project in on schedule, as long as it's understood at the end that the schedule was flawed and steps are taken to ensure that flawed scheduling is not standard operating procedure.
The problem with heroes is that they are often abused by management, which often causes them to leave, or creates a hostile work environment for anyone else who wants to have a life outside of work. You can have bad code that is also error-free; it's bad, because it is unmaintainable and woe is you if your "hero" is gone or too busy to translate it.
Give me software engineers, who can give valid schedule estimates and solid designs, over heroes any day. There's no mediocrity in project management that doesn't require heroes.
Sign in to Reply
snickels
9/1/2010 11:40 AM EDT
I totally agree with this comment. If your project is out of control and you need a "hero" to save the day, give your thanks to the hero, but you really need to figure out why your project got out of control in the first place. BTW, be careful of the developers that do sub-quality work and then come through last minute and look like a hero.
In my book, sometimes extra hours are necessary because of "unknowns" that were assumed at the start of the project, but an excessive number of extra hours indicates a project out of control.
Sign in to Reply
BD
8/26/2010 12:53 PM EDT
Unfortunately, absolute quality is not really a concern for the consumer-electronic industry.
Basically, if you can pass the QA testing procedure, then you have acceptable quality for consumer (This is true even for major Japanese company).
Well, we do have constraints as the management always say..
But, I do resent those companies says "Quality is a concern", there is no-plan, no-metric, no-improvement over the years..
It is a miracle that we are still survived.
Sign in to Reply
Expat Canuck
8/26/2010 3:17 PM EDT
I've seen code that would make the Therac 25 project look good, and yet this stuff is delivered to customers all the time. Most are happy just to get something that "sort of works".
Mediocrity, however, has a price and that price is lost profits because precious development time is chewed up in the resolution of customer complaints.
In many companies the first thing to be cut in a crisis is the book allowance and/or the training allowance. This however does not absolve us as developers of our responsibilities to ourselves in learning as much as we can about our craft.
Years ago, Tom DeMarco and Timothy Lister discovered that most software engineers don't read technical books. If we are going to solve the mediocrity problem we must do it for ourselves first.
Sign in to Reply
Bob.D
8/28/2010 7:44 PM EDT
I knew there had to be another reason I like reading your columns: now I know we have youth hockey in common - I'm a grass-roots referee. (Most of the coaches I deal with really do care - mostly a real lot - about who wins or loses, as I'm sure you & your son know.) I recommend Ed Wenck's "Hockey Dad Chronicles" since I think you'd enjoy its humor.
How do you feel about Holiday Inn Express? I've stayed at a few of them and I'm still trying to figure out what's Express about them....
@lwriemen: I agree with you. Before kids, I wouldn't hesitate to stay late and write or test code, but it's not fair to the wife now. And "Peopleware" has a great example that explains the hostility when not everyone has the flexibility "to work ridiculous schedules".
Sign in to Reply
lifewingmate
8/31/2010 3:28 AM EDT
Clean coding, attention to detail in all forms of the data modeling, architecture, and design of software help decrease or eliminate pain in the long-run. Plus, the product becomes a testimony in and of itself when the developers are proud of their work both inside and out. I am so glad you are basically saying that the appreciation for professionals who go the extra mile is the only thing that we can to do recognize a higher standard of excellence. I appreciate integrity in technology. As we get more competitive on a global level, it is so important that none of us back down from these important ideals and standards.
Sign in to Reply
Mi302
9/1/2010 1:21 PM EDT
Mediocrity starts at the top with a set of expectations and priorities. Expediting (in balance) has replaced excellence (in balance). Companies want to make the most money at what they do as opposed to being the best at what they do to make the most money. Rewards mirror these priorities and presto - mediocrity.
I've personally seen quality work critisized for "taking too long" and requiring unnessesary effort. The unspoken slogan "cheap and easy" reflects managements direction and eventually employees live up to it. Result is inferior junk.
Sign in to Reply
Luis Sanchez
9/9/2010 5:01 PM EDT
Nice article... we do need heroes, let's hope to become one... that is software quality :-)
Sign in to Reply
Patrick Perdu
9/9/2010 7:22 PM EDT
Interesting article.
There seems to be a misunderstanding though about the purpose of CEI's CMM.
The questions CMM wants to answer are:
- Do you have a design process that is repeatable enough to ensure consistent quality?
- Does your process support identifying its own deficiencies and correct them?
Essentially CMM aims at ensuring that the kitchen is clean and that old ingredients are discarded and not fed to the patrons, not to check if the food is good.
A company can be CMM 1 (no process) and still provide great products - it just relies on the individuals to be excellent, and cannot react predictably to e.g. a defection.
It's not that CMM doesn't like heroes, it's that they don't care about the hero part; they care about the repeatable part.
This is where, according to me, CMM falls short to insuring proper quality: for what I call quality you need both the CMM level and the heroes, or at least a certain pride in the team for the job well done.
In your first article you mentioned Steinway and Stradivarius. These were not made by heroes, but by artisans.
Great artisans, admittedly, but not heroes.
That does not mean I don't want heroes in my team - I sure do; but just as I want a great chef in my restaurant, I also need enough process to ensure that the ingredients are fresh and the kitchen is clean.
Now what is enough process?
It depends on the company and on the product.
It should not depend on the individuals, and that's the point.
Huge companies or administrations such as the DoD or Xerox or Honeywell may need something like CMM (Xerox calls it XMM); smaller companies may have to comply in order to do business with these giants.
Startups need heroes.
Sign in to Reply
MikeLC
9/30/2010 4:22 AM EDT
Patrick, I really liked your comments. Well said!
Sign in to Reply
eembedded_janitor
12/5/2010 10:41 PM EST
CMM looks down on heroes because reliance on heros is an inherently non-repeatable.
What happens when that hero is not available for any reason? Try hiring heroes: that just does not happen.
Any model that expects to be repeatable over the long term has to assume that staff of the modeled performance level are readily available. That really limits you to employing average programmers.
Lower level performers need a greater degree of process so that they do not go astray. Better performers often don't need the same level of nannying and resent this.
Sign in to Reply