Unnecessary Code

We were asked, "How can I tell if my code does extra unnecessary work?"

To answer this question well, I’d need to know what you mean by “unnecessary.” Not knowing your meaning, I’ll just mention one kind of code I would consider unnecessary: code that makes your program run slower than necessary but can be replaced with faster code.

To rid your program of such unnecessary code, start by timing the program’s operations. If it’s fast enough, then you’re done. You have no unnecessary code of this type.

If it’s not fast enough, then you’ll want to run a profiler that shows where the time is being spent. Then you search those areas (there can be only one that consumes more than half the time) and work it over, looking first at the design.

There’s one situation I’ve encountered where this approach can bring you trouble. Code that’s fast enough with some sets of data may be unreasonably slow with other sets. The most frequent case of this kind is when the algorithm’s time grows non-linearly with the size of the data. To prevent this kind of unnecessary code, you must do your performance testing with (possibly artificially) large data sets.

Paradoxically, though, some algorithms are faster with large data sets than small ones.

Here’s a striking example: My wife, Dani, wanted to generate tests in her large Anthropology class. She wanted to give all students the same test, but she wanted the questions for each student to be given in a random order, to prevent cheating by peeking. She gave 20 questions to a programmer who said he already had a program that would do that job. The program, however, seemed to fall into an unending loop. Closer examination eventually showed that it wasn't an infinite loop, but would have finally ended about the same time the Sun ran out of hydrogen to burn.

Here’s what happened: The program was originally built to select random test questions from a large (500+ questions) data base. The algorithm would construct a test candidate by choosing, say, twenty questions at random, then checking the twenty to see if there were any duplicates among those chosen. If there were duplicates, the program would discard that test candidate and construct another.

With a 500 question data base, there was very little chance that twenty questions chosen at random would contain a duplicate. It could happen, but throwing out a few test candidates didn’t materially affect performance. But, when the data base had only twenty questions, and all Dani wanted was to randomize the order of the questions, the situation was quite different.

Choosing twenty from twenty at random (with replacement) was VERY likely to produce duplicates, so virtually every candidate was discarded, but the program just ground away, trying to find that rare set of twenty without duplicates.

As an exercise, you might want to figure out the probability of a non-duplicate set of twenty. Indeed, that’s an outstanding way to eliminate unnecessary code: by analyzing your algorithm before coding it.

Over the years, I’ve seen many other things you might consider unnecessary, but which do no harm except to the reputation of the programmer. For example:

* Setting a value that’s already set.

* Sorting a table that’s already sorted.

* Testing a variable that can have only one value.

These redundancies are found by reading the program, and may be important for another reason besides performance. Such idiotic pieces of code may be indications that the code was written carelessly, or perhaps modified by someone without full understanding. In such cases, there’s quite likely to be an error nearby, so don’t just ignore them.

Read: The Psychology of Computer Programming: Silver Anniversary eBook Edition 

Terchnical Reviews and Organizational Renewal

We know that success can breed failured and doesn't automatically renew itself. I would like to offer some ideas on how this self-defeating tendency can be resisted.

One way toward renewal is through new perspectives gained from outside technical audits, but audits suffer from several serious disabilities. For one thing, audits are done intermittently. In between one audit and the next, the programmers don't stop programming, the analysts don't.stop analyzing, and the operators don't stop operating. Sometimes, though, the managers stop managing, And there's the rub.

A comparable situation exists when a firm has a system of personnel reviews mandated, say, every six months for each employee. Under such a system, managers tend to postpone difficult interactions with an employee until the next appraisal is forced upon them. A huge dossier may be accumulated, but then ignored in favor of the last, most conspicuous blunder or triumph. Good managers realize that the scheduled personnel review is, at best, a backup device—to catch those situations in which day-to-day management is breaking down.

In the same way, the outside technical audit merely backs up the day-to-day technical renewal processes within the shop. It may prevent utter disasters, but it's much better if we can establish technical renewal on a more continuous and continuing basis. One way to do this is through a technical team, such as an Agile team. For now, though, I want to introduce, or reintroduce, the concept of formal and informal technical reviews as tools for renewing the technical organization.

The Agile Manifesto requires "technical excellence" and "simplicity," and states: 

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 

To achieve these and other goals, Agile teams conduct "walkthroughs" and "inspections," but these are only two very specific examples of technical review procedures used by Agile teams. In my reading and consulting, I've uncovered dozens of major variants of these two types of review, plus literally hundreds of minor variants that shops have introduced to make the review more suitable to their environments, whether or not they claim to be "Agile."

A more general definition of a technical review could be 

1. a review of technical material on the basis of content (this is what makes it a "technical" review, rather than, say, a financial or personnel review)

2. which is done openly by at least two persons (this is what distinguishes it from "desk checking")

3. who take lull responsibility for the quality of the review (not, please note, for the quality of the product)

Then we distinguish between the informal and formal review. A formal review produces a written report to management. That report is the formal part.

Informal reviews (that is, reviews which need not terminate with a written report to management) are also excellent devices for an organization's self-renewal. Informal reviews take all forms of technical reviews, and are practiced everywhere almost all the time. Indeed, they are an essential part  of the real world of programming work.

For instance, a team member passes a diagram to a teammate for an opinion on how to represent a particular design. Someone asks help from someone else in finding an error. A set of test cases is passed around to see if anyone can think of something that's been overlooked. One person reads another's user document to see if it's understandable.

Without a constant flow of such informal reviewing of one another's work, programming any meaningful project would be impossible. Formal reviewing, on the other hand, is not essential to programming. Many small projects are accomplished without formal reviewing, which is why some programmers don't appreciate the need for formal reviewing. 

As projects grow 'larger and more complex—as they are inclined to do in successful shops—the work of many people must be coordinated over a long period of

time. Such coordination requires management—though not necessarily managers—and such management requires reliable information. Formal reviews, essentially, are designed to provide reliable information about technical matters—particularly to non-technical people.

Clearly, a successful system of formal technical reviews—that is, a system that provides management with reliable information on technical matters—is essential to management participation in the organizational-renewal process. For the large shop, formal reviews provide information that the small shop manager gets "through the seat of the pants." Many, many failures of previously successful programming organizations an be traced directly to the breakdown of the earlier informal mechanisms for communicating reliable information about technical matters.

There may, of course, be other ways of getting this kind of information, and many smaller shops do an excellent job without any system of formal reviews. Even those shops, however, may benefit from an explicit system of reviews to supplement their implicit, or informal, existing system. 

Principally, the formal technical review provides reliable self-monitoring. An informal system may work just as well as a formal one, and if so, there are many reasons to prefer to keep the reviewing informal. In any case, there will always be an informal system at least supplementing the formal one, but we should really view the formal system as supplementing the informal. Its formality guards against creeping deterioration of the organization.

Regular reviews of specifications, designs, code, test plans, documentation, training materials, and other technical matter have many beneficial "side effects" on the health and success of an installation. Reviews have a very marked effect on maintenance—that quicksand in which a thousand successful shops have met an untimely end. A typical program that has been thoroughly reviewed during its development will

1. require less maintenance work per change

2. require fewer changes caused by poor specification, design, coding, or testing.

Instituting a program of technical reviews will not, of course, have any immediate effect on the existing burden of maintenance carried like an albatross from a sinful programming past. Indeed, when maintenance programmers participate in reviews of newer code, they may be further discouraged by the poor quality of the code with which they are burdened. But, the situation can improve rather quickly, for a variety of reasons:

1. Some new ideas can be applied even to patches to old programs, though naturally limited by poor existing structure and style.

2. Through mutual participation in reviews, the entire shop quickly obtains a realistic and sympathetic picture of the true dimensions of the maintenance situation.

3. The worst maintenance problems will, through frequent reviews, become exposed to fresh air and sunlight.

Quite frequently, installation of a review system is quickly followed by replacement of the most cantankerous old beasts left over from the Stone Age of Programming. The effect of even one such replacement on maintenance morale is a wonder to behold,

Other activities besides maintenance are similarly affected. In the long run, certainly, reviews have a remarkable effect on staff competence, perhaps the most important element in continuing success. We also see increased morale and professional attitude, reduced turnover, more reliable estimating and scheduling, and better appreciation of the management role in project success. (Usually, the technical staff has had no difficulty in appreciating the management role in project failure.)

At the same time, reviews provide management with a better appreciation for staff competence, both individually and collectively. The unsung hero who quietly saved a dozen shaky projects is now sung far and wide. The "genius programmer" who was always the darling of the executives has been exposed for the empty and obsolete shell the technical staff always knew, but couldn't expose to management.

No other factor is more depressing to a technical organization than misappraisal of technical competence by non-technical management. The openness of technical reviews marks an end to that misappraisal era. No longer will we all feel cheated by charlatans and incompetents.

As a consultant, I visited dozens of installations every year. The best way to summarize the effects of properly instituted reviews is to report that after five minutes in an installation, I can tell—without asking directly—to what extent there is an effective review-practice, formal or informal.

How do I tell? Metaphorically, I tell in the same way a government health inspector tells about a food processing plant—by the way it smells. It's hard to describe, but when you smell the difference, you-know it!

* * * * * *

Looking back over this essay, I sense its inadequacy to the task at hand. Those programmers and analysts who have experienced a shop with a properly functioning system of reviews will know all this without my giving any details. They've experienced it, and if they are professionals, they'll never agree to work in any other kind of environment.

But those who have never experienced such an environment of a self-renewing organization will not understand, or will misunderstand, what I've written. Some of them will have experienced a misguided attempt to institute reviews. Perhaps the attempt was in the form of a punitive management mandate. Perhaps it was merely a case of another programmer who read one article and blundered ahead with 99% enthusiasm and 1% information—and zero human feeling. To these people, the experience of "reviews" will have left a bitter taste, or a painful memory. They will not recognize their experience in what I've written.

In many ways, technical reviewing is like bicycling. Up until the time you first discover your balance in one miraculous instant, the whole idea seems impossible, contrary to nature, and a good way to break a leg. Indeed, if you'd never seen a cyclist before, and had the process described to you, you'd most certainly declare the whole procedure impossible. And, without instruction and encouragement from experienced cyclists, along with reliable "equipment," the most likely outcome would certainly be skinned knees, torn pants, and a few lumps on the head. And so it has been with technical reviews—until now—-so don't go off and try to learn the whole process on your own.

If you want to get started renewing the success of your own shop through a system of technical reviews, find an experienced shop, or a person from an experienced shop, to guide you. Listen to them, Read the literature. Then try a few simple reviews on an experimental basis, without much fanfare.

Adapt the "rules" to your own environment. Be forgiving and humane. Your rewards  will not be long in coming.

references: 

Handbook of Technical Reviews, 4th ed.

Do You Want To Be A (Better) Manager?

How do I become a programmer who gets stuff done?

The young man wanted to know, "How do I become a programmer who gets stuff done?" He received a number of good answers, like how to organize his work and schedule his working hours. Yet I had a different view of things, so I gave a different sort of answer, as follows.

Some good advice here, yet even if you do all these suggested things, you may be having a different problem. When you speak of getting stuff done, you may be speaking of “finishing” things.

Defining what “done” means has been a classic programmer problem for more than 50 years. Part of the problem is that programmers with different personalities have different ideas about what “done” means. For instance, look at the situation from the point of view of MBTI personality temperaments:

NTs tend to think a project is done when they have a clear description of the problem and a general approach to solving it. Someone else can work out the details.

SJs tend to think a project is done when it’s “code complete”—though research at Microsoft and other places seems to indicate that only about two-thirds of the eventual code has been written by that supposed benchmark. Perhaps this work isn't thought of real programming, but only "clean up."

NFs, such as me, tend to think that a project is done when everyone involved is satisfied that it’s done. Of course, because these "others" are of various personality types, our NF estimate of "done" isn't very reliable.

SPs tend to think a project is done when they are bored with doing it. They share this feeling with lots of other temperaments, too. Programmers in general don't tolerate boredom very well.

Not taking that last step to "clean up" is a curse of our profession, leaving many programs in a less-than wholesome state. Unclean, unfinished programs are the source of many maintenance problems, and of many errors shipped to customers.

Of course, this classification is only a rough model of non-finishers. Many good programmers of all temperaments are excellent finishers, having taught themselves to be aware of their tendencies and counter them with a variety of tactics. Primary among those tactics if the technical review by peers (which is an integral part of the Agile approach but  by no means is not confined to Agile).

So, you offer your “finished” project to your peers for review, and if they agree that it’s finished, you’ve truly gotten something “done.”

If they don’t agree that your work is done, they will give you a list of issues that you need to address before you’re “done.” You then go back to work and address these issues, then resubmit the newest version to another technical review.

Finally, you iterate in this reviewing process until your work passes the review. Then you know you’ve gotten something done.

For more detail on the review process, see, 

Handbook of Technical Reviews, 4th edition

How do I get better at writing code?

Nobody writes perfect code. Anyone, no matter how experienced, can improve. So, you ask, how do I get better at writing code?

Of course, to get better at writing code, you must practice writing code. That much is obvious. Still, just writing the same poor code over and over, you're not likely to improve by much.

Writing is a different skill from reading, but reading code is necessary if you want to improve your writing. As with writing natural language, you build up your skill and confidence by reading—and not just reading your own output. So, find yourself some examples of good, clear code and read, read, read until you understand each piece.

Be careful, though. There’s lots of terrible code around. You can read terrible code, of course, and learn to analyze why it’s terrible, but your first attention should be on good code. Excellent code, if possible.

Where can you find good code? Textbooks are an easy choice, but be wary of textbooks. Kernihan and Plauger, in their book, The Elements of Programming Style, showed us how awful textbook code can be. Their little book can teach you a lot about recognizing bad code.

But bad code isn't enough. Knowing what's bad doesn't necessarily teach you what's good. Some open source code is rather good, and it’s easy to obtain, though it may be too complex for a beginning. Complex code can easily be bad code.

Hopefully, you will participate in code reviews, where you can see lots of code and hear various opinions on what’s good and what’s less than good.

Definitely ask you fellow programmers to share code with you, though beware: not all of it will be good examples. Be sure the partners you choose are able to listen objectively to feedback about any smelly code they show you.

If you work alone, use the internet to find some programming pen pals.

As you learn to discern the difference between good and poor code, you can use this discernment in your reading. After a while, you’ll be ready to start writing simple code, then work your way up to more complex tasks—all good.

And date and save all your code-writing examples, so you can review your progress from time to time.

Good luck, and happy learning!

Who is Right, and What is to Be Done About It?

A management consultant, whose client was an international manufacturer, was asked to evaluate an inventory management procedure that the client had used with stunning success in their French operations. As part of his study, he wanted to compare the performance of the French procedure with procedures used in other locations, using historical data from several countries. A programmer with a strong management science background was given the job of programming the simulation of the French procedure.

When the consultant received the results he could not reconcile them with the figures supplied by the French company. After extensive checking he initiated a series of long telephone calls to France, suggesting that perhaps the procedure had not actually performed as well as they had claimed. The French management took offense at the implication of incompetence.

The French manager complained to the manager who had hired the consultant. Tempers mounted and international relations were strained to the breaking point.

By sheer chance, someone examined the programmer's simulation program and noticed that one term was missing and a second term was negative rather than positive. These findings led to a full technical review of the formula as translated. The review showed that the programmer's formula did not match the formula supplied by the French.

The consultant, much relieved, took the program back to the programmer and showed him the error. "That's not an error," the programmer protested. "Actually, the formula was in error, so I corrected it. The formula I programmed is correct, whereas the original formula was simply wrong."

That's the end of Part 1.

Note to Readers
Now, for you readers, the question is this:

"If you were the consultant, how would you handle this situation going forward?"

If I receive a few comments, I'll publish the rest of the story—what actually happened.

And please note: I don't accept anonymous comments. They're automatically rejected. By all means, use a pseudonym, but don't waste your effort trying to post anonymous comments.

Change Artist Challenge #6: Being Fully Present

It always seems to me that so few people live—they just seem to exist—and I don't see any reason why we shouldn't LIVE always... - Georgia O'Keeffe

In order to be a successful catalyst for change, you must learn the art of being fully present. To be fully present, you must:
1. Pay full attention to the speaker.
2. Put aside any preconceived ideas of what the speaker is going to say.
3. Interpret descriptively and not judgmentally.
4. Be alert for confusions and ask questions to get clarity.
5. Let the speaker know that he/she has been heard, and what has been communicated.




Here are a number of common hindrances to being fully present:

   • Ignoring: lack of attention (looking elsewhere, fidgeting), boredom, disinterest, pretending to listen

   • Selective listening: hearing only parts

   • Sidetracking: changing the subject (without proper transition); telling your own story; making light of, with inappropriate humor

   • Evaluative listening: agreeing or disagreeing before the explanation is finished

   • Probing: asking too many questions (from your frame of reference) with little sense of the person

   • Interpretative listening: explaining what's going on based on your own motives and behavior

   • Advice giving: offering solutions; focusing too much on content

The Challenge
Your challenge is to pick one habit that keeps you from being fully present, and focus on reshaping that habit in all your interactions.


Experiences
1. I decided to try going through a meeting without telling any jokes. I didn't actually make it all the way, but they seemed to appreciate my joke more, when I finally told it.

2. I didn't really know what to do, as I thought I was a good listener. I got a support person who told me that I should stop reading my mail during meetings. That really surprised me, because I thought myself so good a listener that I could read mail and listen at the same time. Besides, it kept me from interrupting. My supporter told me that even though I might be hearing everything that was said, my reading made it look like I wasn't paying attention, or at least didn't care what was being said.

3. I'd read about not giving solutions during review meetings, but I was strongly opposed to the idea. It just didn't make sense to me. But, since I had to do this assignment, I decided to try doing one review without offering any solutions. I did have two solution to offer, but the author came up with one of them a few minutes later, before I said anything about it. Actually, I guess it was pretty obvious, and if I'd said it, he probably would have thought I considered him stupid. I saved the other until after the meeting, and it was really appreciated. It seemed to be a pretty good review, actually one of the better ones I've ever attended.

4. I have to tell you that I'm known around here for being the person who can get anything out of anybody with my penetrating questions. I decided to try a new tactic. Whenever I found myself thinking of a neat question, I caught myself and asked, instead, "What else do you want to tell me?" I got just as much information as I ever get, so maybe I'm not such a great questioner as I thought. Or maybe I'm greater—I can do it with just one question!

5. I looked at whoever was speaking. Every time. I had been missing a lot, not seeing facial expressions and posture. I think I'll do it again.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

Change Artist Challenge #5: Being The Catalyst

Look abroad thro' Nature's range.
Nature's mighty law is change. - Robert Burns

Although change artists often work as prime movers, they more often work through understanding natural forces and creating slight perturbations of Nature. In this challenge, you will practice facilitating the change projects of others, using various ways of empowering from the position of catalyst. In chemistry, a catalyst is a substance that added to a reaction accelerates that reaction by its presence, without itself being changed by the reaction.

A human catalyst is someone who rouses the mind or spirits or incites others to activity with a minimum of self-involvement—in other words, by empowering others. For people to be empowered to change their organization, the MOI model tells us that the following ingredients are required:


Motivation
• self-esteem
• a value system and a vision held in common
• a sense of difference between perceived and desired

Organization
• mutuality of support, based on personal uniqueness
• a plan for reducing the perceived-desired difference
• a diversity of resources relevant to the plan


Information
• a systems understanding of what keeps things from changing
• an understanding of empowerment versus powerlessness
• continuing education appropriate to the tasks

Often, only a single ingredient is missing, but the person who doesn't know which one it is can feel completely disempowered. The recipe suggests which ingredient might be missing. A change artist who supplies that missing ingredient can catalyze change with minimal effort.


The Challenge

Your challenge is to facilitate other people's change projects, approximately one per week, for at least two weeks. You should attempt to be a catalyst, for change, not the prime mover for change. To be a catalyst, you should involve yourself

• as effectively as possible

• in the smallest possible way

• without depleting your capacity to catalyze other changes

If possible, use each ingredient of this recipe for empowerment at least once. Keep notes in your journal and be prepared to share learnings with the group you are catalyzing.

Experiences
1. A group in the shipping department asked me to help them run their planning meetings. I said I would do it if they enrolled two people in our facilitation class, and that after taking the class, they would work alongside me. After one meeting, they are now facilitating their own.

2. I led a technical review of the design of a very controversial project, and apparently I did a good job because I got three other invitations to lead difficult reviews. I did lead two of them, but I decided to try being a catalyst on the third. I told them I wouldn't lead the meeting, but I would play shadow to a leader of their choice and we would switch roles if their leader got in trouble. She didn't.

3. One of my groups wasn't using—or even attempting to use—the new configuration control system. Ordinarily, I would have ordered them to use it, with threats of reprisals. I thought about the minimum thing I could do—with no force and no blaming—to get them moving. I decided to call them in for a meeting and give them the problem of how to get them moving. They told me they just didn't have time to switch their partially developed project to the new system. I asked them how much time they would need. They huddled and came up with a two-week extension to their schedule. (I had been afraid they would say two months.) Since they were off the critical path, I said they could have the two weeks, but only if they switched to the new system. They actually did the job in one week, and in the end, they made up four days of that—partly, at least, because of using the better tool. I've now used this consultation method several more times. "What would you need to give me what I need?" turns out to be a great catalyst. I like being a catalyst much more than being a dictator.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

No More Reviews—With Exceptions

My call for reviewers has been so successful, I'm flooded with requests for free books.

For the moment, I'd like to suspend the reviewing (until next time) with the exception of readers who are willing to review some of my novels—which are under-reviewed.

So, if you want to review one of my novels, let me know. If you're interested in one of the non-fiction, you'll have to buy it (the e-book versions are very inexpensive) or wait until the next free book offer.

For the novels, you can see them and sample them at

http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg

And thanks to everyone who has responded.

Free books! Looking for a Few More Book Reviewers

This post is about marketing. As you probably know, I'm in the business of writing books, as part of my consulting business (or vice versa). In the modern publishing world, with more and more books bought online, customer reviews really can help books reach their full potential. Although we work with professional reviewers as well, you don’t need to be a professional reviewer to review books for me. Any avid reader can do it!

Right now, I'm looking for a few more people to help spread the word about my books. If you’re interested, please email me at hardpretzel (at) earthlink.net with the words “Book Reviewer” in the subject line.

I’ll email you back with a password that will give you access to one of my titles in Kindle, PDF, and ePub format, for your computer or your reading device.

Here’s my current titles, with more on the way:

http://www.geraldmweinberg.com

All I ask is that you review whatever book you download on either Amazon or Smashwords or Barnes and Noble’s website (or all three—that’s even better). If you’re a professional reviewer, it’s great if you review it on your blog or website, and I’ll often link to it from my own site, but I still ask that you post your review to at least one of the three just mentioned.

It’s easy to do, and you don’t even need to use your real name if you like. Five or six sentences is fine, though you can certainly write more if you wish. Have fun! And if you’re not sure how to do it, just read some examples.

Please note: It would be unethical to require you to do a positive review; all I ask is that you’re fair, and that if it’s just not your kind of book (remember, everyone has different tastes), that you just pass on doing the review at all. In the modern book selling world, these reviews have become critically important to helping books reach their full potential. Keep this in mind when you’re reviewing and you’ll be just fine: I’ve staked many hours on my novels and nonfiction.

I can give away only so many free books, so I’ve limited this round of book reviewers. If interested, please email us ASAP.*

(Thanks for this idea to Scott at Flying Raven Press, http://flyingravenpress.com/. Why not give them a visit.)

Testing Without Testing

The job of software testing, we know, is to provide information about the quality of a product. Many people, however, believe that the only way to get such information is to execute the software on computers, or at least review code. But such a belief is extremely limiting. Why? Because there's always lots of other information about product quality just lying around for the taking - if it were only recognized as relevant information.



Because of their psychological distance from the problems, external consultants are often able to see information that escapes the eyes and ears of their clients. Dani (Jerry's wife) tells this story about one of her consulting triumphs in the dog world:



======================================================



A woman with a Sheltie puppy was at her wits' end because "he always poops on the living room rug." She loved the little guy, so before giving up and taking him to the Humane Society, she came to Dani for a consultation. Dani listened to the woman describe the problem, then asked, "Are there any other behavior problems you've noticed?"



The woman thought about that for a while, then said, "Well, yes, there is one. He has this annoying habit of scratching on the front door and whining."



======================================================



It's easy to laugh at this woman's inability to see the connection between the two "problems," but that sort of blindness is typical of people who are too close, too emotionally involved, with a situation. Learning to recognize such free information is one of the secrets of successful testing. Using it, you can learn quickly about the quality of an organization's products or the quality of their information obtained from machine testing.

Here are some "Sheltie stories" from our consulting practices. Test yourself by seeing what information you can derive from them about the quality of a product or the quality of the information that's been obtained about the product through testing:



======================================================



1. Jerry is asked to help an organization assess its development processes, including testing. Jerry asks the test manager, "Do you use specs to test against?"



Test manager replies, "Yes, we certainly do."



Jerry: "May I see them?"



Test manager: "Sure, but we don’t know where they are."



======================================================



2. Jerry is called in to help a product development organization's testing group. He learns that they are testing a product that has about 40,000 lines of code.



"The problem," says the test manager, "is with our bug database."



"What's wrong with it," Jerry asks. "Is it buggy?"



"No, it's very reliable, but once it holds more than about 14,000 bug reports, its performance starts to degrade very rapidly. We need you to show us how to improve the performance so we can handle more bug reports."



======================================================



3. Bunny is asked to help improve the testing of a large product that has 22 components. The client identifies "the worst three components" by the high number of bugs found per line of code. Bunny asks which are the best components and is given the very low bugs per line of code figures for each.



She then examines the configuration management logs and discovers that for each of these three "best" components, more than 70 per cent of their code has not yet successfully been checked in for a build.



======================================================



4. Trudy is invited to help a development manager evaluate his testing department's work. She starts by looking at the reports he receives on the number and severity of bugs found each week. The reports are signed by the test manager, but Trudy notices that the severity counts have been whited out and written over.

"Those are corrections by the product development manager," the development manager explains. "Sometimes the testers don't assign the proper severity, so the development manager corrects them."



Using her fingernail, Trudy scratches off the whiteout. Under each highest severity count is a higher printed number. Under each lowest severity count is a lower printed number.



======================================================



5. Jerry is watching a tester running tests on one component of a software product. As the tester is navigating to the target component, Jerry notices an error in one of the menus. The tester curses and navigates around the error by using a direct branch.



Jerry compliments the tester on his ingenuity and resourcefulness, then asks how the error will be documented. "Oh, I don't have to document it," the tester says. "It's not in my component."



======================================================


6. Fanny watched one tester spend the better part of several hours testing the scroll bars on a web-based enterprise system. The scroll bars were, of course, part of web browser, not the system being tested.



======================================================



7. Jerry asked a development manager if the developers on her project unit tested their code.

"Absolutely," she said. "We unit test almost all the code."



"Almost?" Jerry asked. "Which code don't you unit test?"



"Oh, some of the code is late, so of course we don't have time to unit test that or we'd have to delay the start of systems test."



======================================================



8. One of Christine's clients conducted an all-day Saturday BugFest, where developers were rewarded with cash for finding bugs in their latest release candidate. They found 282 bugs, which convinced them they were “close to shipping.”



They were so happy with the result that they did it again. This time, they found 343 new bugs - which convinced them they were “on the verge” of shipping.



======================================================



9. A general manager was on the carpet because a recently shipped product was proving terribly buggy in the hands of customers. Jerry asked him why he allowed the product to ship, and he said, "Because our tests proved that it was correct."



======================================================



10. Another manager claimed to Noreen that he knew that their product was ready to ship because "we've run 600,000 test cases and nothing crashed the system."



======================================================



11. When Jerry asked about performance testing, one of his clients said, "We've already done that."



"Really?" said Jerry. "What exactly have you done?"



"We ran the system with one user, and the response time was about ten milliseconds. Then we ran it with two users and the response time was twenty milliseconds. With three users, it was thirty milliseconds."



"Interesting, Jerry responded. "But the system is supposed to support at least a hundred simultaneous users. So what response time did you get when it was fully loaded?"



"Oh, that test would have been too hard to set up, and anyway, it's not necessary. Obviously, the response time would be one second - ten milliseconds per user times one-hundred users."



======================================================



12. Jerry's client calls an emergency meeting to find out "why testing is holding up our product shipment." In the meeting, the testers present 15 failed tests that show that the product did not even build correctly, so it couldn't be tested. They discuss each of the 15 problems with the developers, after which the development lead writes and email summary of the meeting reporting that there are only two "significant" problems.



The email goes to the development manager, the marketing manager, and all the developers who attended the meeting. None of the testers present are included in the cc-list, so none of them even know that the email was sent.



======================================================



13. Johnson watches a tester uncover five bugs in a component, but instead of logging the bugs in the bug database, the tester goes directly to the developer of the component and reports them orally. Johnson asks why the tester didn't record the bugs, and he replies, "If I do that, she (the developer) screams at me because it makes her look bad."



======================================================



14. Tim reviews a client's test plan and notices that there is no plan to test one of the components. When he asks the test manager (who is new to the company) why it's missing, he's told, "We don't need to worry about that. The development manager assures me that this developer is very careful and conscientious."



======================================================



So, were you able to extract meta-information from these ten examples? What did each of them tell you (or hint to you) about the quality of the information from testing - the accuracy, relevance, clarity, and comprehensiveness?

Remember, though, that these are merely hints. Perhaps the Sheltie pooped on the rug because he had some medical problem that would need a veterinarian's help.

Perhaps there's a non-obvious explanation behind each of these Sheltie Situations, too, so you always have to follow-up on the hints they provide to validate your intuition or find another interpretation. And, even if your intuition is right on target, you probably won't have an easy time convincing others that you're correct, so you will have to gather other evidence, or other allies, to influence the people who can influence the situation.



When Dani asked the Sheltie's owner why she thought the pup was whining at the front door, the woman said, "I think I've spoiled him. He just wants to go out and play all the time, but I have too much housework to do - especially since I spend so much time cleaning up the mess on the rug."



When a problem persists in spite of how obvious the solution is to you, you aren't going to be able to convince others to solve the problem until you find out how they are rationalizing away the evidence that's so apparent to you. So we need to know how people immunize themselves against information, and what we can do about it.

(Adapted from Perfect Software: and Other Illusions about Testing)
http://www.smashwords.com/books/view/25400

A Code of Work Rules for Consultants

I frequently meet a consultant who is deeply troubled by the implications of the work of a consultant. What we do today may affect the lives of thousands or millions of people for many years to come.

Moreover, most of those people we affect won't have any way to relate a discomfort in their lives to what we are doing today.

They will, perhaps, sheepishly accept the explanation, "That's the way the computer must do it," or the even more insidious, "that's the way things are."

Some consultants I know, particularly those working in shops where nobody ever looks at anybody else's work, salve their conscience by sabotaging their client's information systems.

In many cases, it's difficult to tell whether this is intentional or unintentional. In other cases, there is no doubt.

Many programmers, analysts, and consultants have complained to me that their work holds no meaning for them. They don't know what is being done with the piece of design or specification they work on, or they know and don't approve.
Their response is to stay on the assignment, draw their fee, and badmouth their client at every safe opportunity.

I think it's time we stood up to be counted. We have an enormous responsibility to the people whose lives will be impacted by the organizations we work for.
If we don't believe in what our client is doing, or we don't understand it, then why are we working there? To draw a fat fee? Then what does that make us?

For some years now, I've been giving a set of principles to consultants who are seeking a new assignment, or are considering changing their present assignment because of such doubts.

In recent years, as the job market shrinks, the number of such doubters seems to be increasing so I thought that many professionals would like to see these principles written down:

1. I will not work for an organization whose goals are not consonant with my beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person's performance against another's. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

Over the years, I've found that people who ask these questions and set those conditions don't wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale.

Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

Many of us lost souls need some guidance, and it might have been easier to have a set of principles when the job market wasn't so tight. But over the years, I've learned that consultants following these principles are more successful at landing good contracts–ones that make them richer and, more important, happier.

How to get a job or assignment

One of my colleagues recently wrote about her difficulty in landing consulting assignments. She has some great unique models, but, as she says, ...

The Problem

Most large companies (w/ no R-D labs) have the resources to take risks but refuse to.

Small companies have the guts to take the risks, but do not have the resources or the macro set of processes to do it. ...

What do you think?

Some Solution Ideas

It's one of the paradoxes of the consulting business.

Sometimes, the trick is to choose medium-sized companies. :-)

Seriously, people retain your services only when they know you enough to trust you. Consequently, my preferred method has always been to have a stepped-variety of offerings so they can start to know me in safe, tiny steps (books, keynote addresses at conferences, blogs, comments on blogs, ) ...

Then have medium steps (like workshops, tutorials at conferences, ) ...

Then larger steps (consulting visits)

Then really big steps (consulting contracts ).

Then retire rich.

Solution Ideas for Getting Hired on a Job

These days, it's not just consultants who are having a hard time finding the work they want. In the same mail, I got the following email from Liam, a recent PSL grad:

"As you were advising me to start looking for a new job in the Spring of '09 at PSL, you won't be surprised that lost my job at XYZ at the end of last year."

Not surprised, but disappointed. Still, in the long run, these changes usually work out for a much better situation. Losing the job is just confirmation of a lousy situation.

"I am still looking and would welcome any ideas or advice you might have."

The Problem of Getting Hired on a Job

Well, I just finished an email to another grad who's trying to establish his consulting business (which is getting a number of jobs, so there are many similarities). I'll quote what I told him:

Sometimes, the trick is to choose medium-sized companies.

***[Liam: this might apply to job-hunting, too. In any case, whatever you're doing now, change something--bigger, smaller, more or less medium, you know.]

My preferred method, though, has always been to have a stepped-variety of offerings so they can start to know me in

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

- Then have medium steps (like workshops, tutorials at conferences, ) ...

- Then larger steps (consulting visits)

***[Liam: interview visits, but also visits to help you show off by
doing something for them that's specialty of yours, just a talk, maybe]

- Then really big steps (consulting contracts).

***[Liam: hiring, which is a really big step these days, so perhaps hiring for a trial period, to minimize their risks]

Then retire rich.

Applying My Own Advice

Well, I'm already rich, haven't wanted a "job" for half a century, and have more consulting requests than I can handle. BUT, I'd like to be "hired" more often in my new "career"–writing fiction that entertains while teaching, or teaches while entertaining. I'm trying to apply my own advice to this new situation:

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

***[Jerry: A book is already "tiny" for your consulting business, but in the book business, that's it! Well, no it isn't, so I'm trying to make samples available (see one example below in the Appendix, my email signature, which is another tiny step) ]

- Then have medium steps (like workshops, tutorials at conferences, ) ...

***[Jerry: I offer workshops and tutorials for writers (writers are a small part of my potential audience, yet can be quite influential). I set up a book table at conferences, where people can actually put their hands on books. I've tried book-signings, but they're pretty painful when nobody shows up. And larger samples.]

- Then larger steps (consulting visits)

***[Jerry: I haven't really figured out how to do this. Well, I've just become a member of Book View Café, a writers' cooperative, where I have serialized one of my books for free, and will blog pretty regularly http://www.bookviewcafe.com]

- Then really big steps (consulting contracts).

***[Jerry: I've had some offers to write books-for-hire, but that's too much like a job. I suppose I'm fantasizing that some huge publisher will see one of my books and offer to make it into the next Harry Potter, but that's just a fantasy. And if they offer me a movie option, I'll turn it down. I used to live near Hollywood, and the smell of it was more than enough for me. (but I do love going to movies, but I saw what they did to the book of a friend of mine--and no thanks. He now wears a t-shirt that says, "Don't judge a book by its movie.")]

Then retire rich.

***[Jerry: You already did that, so take $$$ out of the equation. Write for fun, but get as many readers as you deserve, neither more nor less.]

A Cry for Help

After sending those two replies to my students, I immediately realized I had failed to mention the most important possible solution. (Isn't that what always happens when you hit the SEND button? Maybe I should sell SEND buttons to writers who need inspiration.]

What's that solution idea? Obviously:

- ask your friends for solution ideas.

So, friends, any ideas for my fiction business?

- And, oh, yes, you can ask your friends for jobs/assignments.

So, friends, I wouldn't object if you bought a book or two.

- Motivate them, or why would they want to do it.

Well, I believe my books ought to be self-motivating, but I have to motivate potential readers to actually look at them. So, perhaps because you know my non-fiction, or my teaching, you might be motivated to buy one of my books (either e-book or paperback). And, if you read it, and don't like it, I'll personally refund your money.

But if you do like it, I wouldn't object at all if you told me, and even wrote a review of it for Amazon, Smashwords, Powell's, your blog, or any other place that accepts reviews. If you do, I'll give you the free book of your choice, as a small thank you. Heck, I'll even give you your money back, if that's what you prefer.

And, yes, I really mean it.



Appendix: My Email Signature Inviting Sampling

How to sample my novels (try before you buy):

Suggestion: Go to the CreateSpace website for each of the books below and see a short description of the book.

Or, if you want a sample, click on , then click on a title you're interested in sampling, then "buy" the book and ask to see the sample.

Or, for most of the books (not fully updated yet) you can read smaller samples on my website (below).

http://www.geraldmweinberg.com/Site/eBOOKS.html



Or, if you prefer them as quality paperbacks:
First Stringers: https://www.createspace.com/3463980
Second Stringers: https://www.createspace.com/3464933
The Hands of God: https://www.createspace.com/3466119
Mistress of Molecules: https://www.createspace.com/3390916
Freshman Murders: https://www.createspace.com/3469259
The Aremac Project:
Aremac Power
Earth's Endless Effort