© 2003 Gerald M. Weinberg, www.geraldmweinberg.com

P.T. BARNUM said there’s a sucker born every minute, but Barnum was a conservative estimator — or else he didn’t know any IT managers. For more than 45 years now, I’ve watched an endless stream of technical “solutions” being promoted, sold, and quickly put on the shelf and forgotten.

Come to think of it, forgetting these “solutions” is not such a bad result. As someone once said: “A problem is the solution to the previous problem.” At least forgotten solutions don’t become bigger problem than they were supposed to solve.

Remember COBOL? What was it supposed to solve?

As Jean Sammet recalls in her History of Programming Languages, the users for whom COBOL was designed were two subclasses of those people concerned with business data processing problems.

One is the relatively inexperienced programmer for whom the naturalness of COBOL would be an asset, while the other type of user would be essentially anyone who had not written the program initially.

Little solutions

In other words, the readability of COBOL would provide documentation to all who might wish to examine the programs, including supervisory or management personnel. Little attempt was made to cater for the professional programmer.

I have clients today who are maintaining, with professional programmers, tens of millions of lines of COBOL code — and no supervisory or management personnel would dare to look at a single line, let alone change one.

COBOL solved some little problems, but left us with a much bigger one. Because these organizations are busy chipping away at the incredible mountain of maintenance, new development work of organizations falls behind.

Like addicts deprived of their drugs, the customers are eager for a “quick fix,” and ready to deal with any pusher. One quick fix is called “rapid prototyping.” Almost all of the “rapid prototyping” I’ve so far seen hasn’t been all that rapid, but that doesn’t matter, because it hasn’t been prototyping either.

I know that statement will bring letters from a hundred vendors agreeing with me – except as far as their product is concerned. But that’s not the battle I want to fight. Nor am I concerned that where prototyping works, it often works backwards. In building airplanes, for example, a prototype often leads to a higher rate of failure in the final version because the prototype makes the builders overly ambitious about the successor.

But let’s put these little quibbles aside and assume that everyone’s rapid prototyping system is both rapid and prototyping. Let’s grant that they work (after all, COBOL worked) and contemplate some of the consequences.

Santayana said that those who failed to study history were condemned to repeat it. I suggest we study the history of that earlier rapid prototyping language, COBOL, so perhaps we won’t all repeat it.

Although many today consider COBOL a failure, objective analysis says it was a great success. If it hadnít been a success, we wouldnít have billions of lines of COBOL code to maintain.

Here is a riddle: How do you accumulate a billion lines of COBOL code? Answer: one line at a time. In most cases, thatís literally true, because very few of those billions of lines consist of original code. Over the years, as requirements changed, the COBOL programs have changed. Studies indicate that in a mature COBOL program, there have been three lines written for every one that remains in the code.

It took many programmers many years to accumulate those billions of lines, one line at a time. But we’re lucky, because now that we can program so much more rapidly, we won’t have to wait as long to accumulate our mountain of rapid prototype code.

In fact, now that we’ll eliminate the professional programmer, we’re going to have 100 times as many people developing prototypes. It took us half a century to get into the COBOL mess, but with rapid prototyping we can surpass that in a few weeks.

It’s not just the volume of COBOL code that causes the huge maintenance effort. Volume must be multiplied by a quality factor, because low quality code takes more effort to maintain. Yes, I know rapid prototyping languages are supposed to produce more readable code — but have you looked at any? Have you seen what happens after the users have made a few changes?

Lessons of history

History teaches us that when the users do actually make those changes, their ambition quickly outstrips their skill and the capacity of their language. At this point, they turn to the more experienced — the professional programmers who already are buried in COBOL code.

Again from history, we know that the more different people using code or data, the more constraints there are when it comes time to change. The amount of constraint makes each change more difficult, so a constraint factor must be added to the maintenance effort equation.

There may be some hope of controlling all this, but history teaches that most IT managers are going to go into a dopey daze in the sand while this quick fix enters the bloodstream of their organization. They can look forward to more maintenance, more difficult maintenance, done under greater constraints, with greater shortages of professional staff. Because they’re in a dopey daze, however, they won’t be looking forward at all.

The only people who can resist a quick fix are those that are not addicts. The only organizations that can avoid turning the maintenance solution into a maintenance trap are those that already have their maintenance under control. But that takes good management, for which there is no quick fix.

The moral of this story for my readers: Don’t despair of these hard times! There will always be enough work for those who are willing to slowly fix those quick fixes.

convert this post to pdf.

© 2002 Gerald M. Weinberg, www.geraldmweinberg.com

These days, with all the talk about “internet time,” professional workers are always trying to be the first with new ideas. But is that really the only path to success? Is it, indeed, a very effective path at all? What about being second?

Our culture certainly encourages people to be “first.” In school, the emphasis ranges from who raises a hand first in class to who graduates with the highest grade-point average. The valedictorian – first in the class – gets lots of honors, but the salutatorian – second in the class – has to make the speech (phooey!).

Sports competitions also honor the “winner,” and books on problem solving and business often borrow this metaphor – emphasizing finding the “winning” idea before anybody else. But most problem-solving areas of life are not, in fact, like sports. It?s not having the idea that matters, it?s what you do with the idea that counts.

And, in fact, ideas don?t count that much in sports, either. Anyone can have the idea, “Hit a home run now and win the game,” but there?s a lot more to hitting home runs than simply having the idea. To have a fair chance of hitting a home run, you have to practice, practice, and practice. As in most of life, the key issue is not who is there first with the idea; the key issue is how you develop the idea once you have it. It?s not your ideas alone that win, but ideas plus capability and the will to develop your ideas.

If you think having ideas first is the issue, consider this. Every year, tens of thousands of individuals start businesses based on being the first with a “new” idea. If that was all it took to be wildly successful, many of these firms would quickly displace all of the giant firms and become giants themselves, every year! Yes, we all know stories of small firms that had a better idea and indeed succeeded at becoming giants, but most of the time, the giants persist and the midgets fall humbly by the wayside.

Giant companies survive the onslaught of little start-ups with one of two strategies:
1. Exploring many parallel ideas and developing the few good ones.
2. Letting others do most of the searching for ideas, then developing the few good ones.

What can the individual professional learn from these strategies?

Exploring many parallel ideas depends on having huge amounts of capital, which the individual professional cannot manage. But even giants couldn?t afford to have so many explorations in the pipeline if they didn?t know how to kill the ones that show no promise, and kill them early. So, for the individual, the lesson of this strategy is to learn how to let go.

For me, letting go means not trying to maintain leading-edge competence in every field in which I was once competent. I used to be one of the world?s great IBM 704 assembly language programmers, and I suppose there are still some jobs maintaining such code, but I don?t think I?d want them anyway. I?ve let go of that one, along with dozens of others.

Letting go also means that I don?t try to pursue every new fad I happen to hear mentioned at a conference or on the web – which leads me into the second strategy – letting others do most of the searching for me.
In a field where capital costs are low (like software development), chances are better that some small firm will come up with the good idea first because there are tens of thousands of such small firms out there. In that case, the big successful companies don?t rely on coming up with every good idea first. Instead, they pursue an “always be second” policy, and support it. They maintain some minimal competency in a wide variety of areas, so that they?ll readily recognize one of these good ideas when it comes along – from another company, or often from one of their customers. Then, they?ll either copy the idea, buy the rights, or buy the company.

I?m not able to buy companies, or even their licenses, but I am able to learn from them. And, under some circumstances, I can ally with them. That way, even a single individual can pursue an always-be-second strategy.
To be a great second, I use a process that resembles the way a breeder produces improved plants and animals, with three essential elements: variation, selection, and retention. Variation provides the new ideas; selection weeds out the ones lacking promise; and retention propagates the ones that survive the selection.

Variation (new ideas) for an individual, comes from using a network to supply information from literally hundreds of sources. By communication with people in my network, I can be sure that few new ideas escape my attention. I have created a huge virtual organization, far larger than any real organization I could afford. The AYE Conference is a central element of that network, where I can meeting many of my “nodes” face-to- face once a year and exchange ideas and experiences.

The network provides some of the selection, too. First of all, any idea that nobody passes on to me is unlikely to be a worthwhile idea. Conversely, when I hear of the same idea from three separate sources, I raise its “score.” Of course, in order for this selection process to be meaningful, I have to consider the reliability of my sources. For example, if I hear an idea supported enthusiastically by certain people, I reduce it?s score.
I work hard to keep my network alive and healthy so I can depend on it to do a good job of variation and selection. Ultimately, though, I have to rely on myself to select which ideas are worth retaining and developing, but the whole process is designed to keep me from developing “neat things” that don?t fit the market.

I don?t know how to automate the retention and development of ideas, so it takes a lot of work, and I can?t afford to develop very many new ideas the way a large organization might. Sometime I can share work by co- developing ideas (seminars, books, articles) with colleagues from my network. But ultimately, I have to develop in my own way, to create the unique service I can sell to my clients. This is the place where it pays me to be first – I may be satisfied being second in the race to market, but I always try to be first in quality.

convert this post to pdf.

©2005 Gerald M. Weinberg

We hear a lot these days about “reusable programs,” but we seldom hear about programs that shouldn’t be reused. Most programmers know what it’s like to be forced to reuse code that was supposed to be used only once and then discarded, such as:

1. prototypes, as for simple, quick formatting of output
2. one-time reports
3. test drivers and harnesses
4. research programs to probe some peculiar feature of the programming language, operating system, databse, or other “black box”
5. engineering assist programs, to help diagnose a hardware malfunction

These examples generally fall into two categories:

Frequently retained when they should be discarded:
protoypes and one-time reports, and

Frequently disposed of when they should be kept:
test drivers, research programs, and hardware testers.

That is, though all are thought of as single-use programs, the should-be-discarded software tends to be held somewhere, “just in case.” Only the should-be-kept programs are actually discarded.

If the developer is responsible for the decision, the program is likely to be discarded; but if the customer is responsible, the program is likely to be kept.

Developers discard programs because they understand tha reuse is not free. A program not designed and test for reuse, but brought out of hibernation will cost even if no requirements changes are requested by the customer.

1. The hardware environment may have changed.
2. The system software environment may have changed.
3. The size or format of the data may have changed.
4. The human environment may have chnaged, which might, for example, activate a part of the program that has never been invoked before.
5. Some part of the program or its supporting material may have been lost or damaged.

The longer the period of hibernation, the greater the cost – if for no other reason than somebody must check for one of these five conditions. But you already knew this – we all know this. then why, oh why, do we keep tumbling into the same trap?

I believe the answer lies in our unwillingness or inability to feed back the true costs of program development and program maintenance to our customers. Many software development vendors have reduced the problem to manageable proportions by the following steps:

1. When a program is commissioned, the customer must specify the lifespan and the number of executuions.
2. If there is uncertainty about either of these figures, the vendor bids contingent prices, reflecting the differing costs.
3. The vendor offers a contract stating that the program will be destroyed after a certain time and/or number of executions, whichever comes first.
4. The program remains the property of the vendor, unless the customer takes ownership. In such a case, the vendor places a much higher cost on the job – to pay for preparing the program to be maintained by other than the original developers.
5. The vendor notifies the customer when the program is about to be destroyed, and gives the option (at a substantial and realistic price) of rebuilding the program for further use.
6. If the original contract was for a “one-time” program, no notification is required. Instead, the vendor destroys all copies of the program as soon as the customer has accepted the program’s output.

Inexperienced customers readily accept these terms. So do very experienced customers, who know quite well the realities of “one-time” programs that turn out to be “N-time” programs. Only the in-between customers have difficult accepting these conditions, for they believe – incorrectly – that they understand programming.

In-house IT organizaitons – especially where there is no true chargeback for development or maintenance – have more difficulty teaching these lessons. The users pay nothing for specifying a one-time program and then asking that it be run N times. Without cost, they have little motivation to learn. With chargeback, however, in-house IT organizations can do what good, professional vendors do.

If you work in an in-house IT organization without chargeback, however, you can sometimes achieve relief by manipulating your one available parameter – time. You ask the customer to specify a one-time or N-time program and then give different time estimates for each. The one-time estimate is shorter, but carefully spells out the procedure that will be followed in destroying the program after its first use. Initially, users simply will not believe you will enforce this procedure, so get it in writing. After a few lessons – if you don’t submit to screams and threats – they will begin to understand the true costs. Only then will they devote some energy to making their initial decision of one-time versus N-time.

convert this post to pdf.

©2000 Gerald M. Weinberg, www.geraldmweinberg.com

As some of you know, a group of consultants are producing a conference for our colleagues and clients. It’s called AYE, for “Amplifying Your Effectiveness.” One of the main goals of this distributed project is to apply our own methods of amplifying effectiveness to the project itself, and thereby to learn what works and what doesn’t.

My first big learnings have been in the area of unplanned delays. The project members are distributed all over the United States, and often travelling from their home base — a situation that’s more than familiar to many Contract Professional readers. I was concerned about the difficulties of conducting distributed projects, but one advantage of this potential handicap is the availability of an email record of what’s happening. So, when I started being aware of delays, I surveyed my email and came up with a list of what had been holding us up and frustrating me.

I suspect the list itself will be a nice reminder to me for future planning, so I also thought it would be useful to many Contract Professional readers. After laying out all the delays and what we’re doing about them, I’ll present a few general principles that might also be helpful to others:

1. One project member’s email is somehow delayed in cyberspace for 2-3 days, without anybody knowing it. The result is messages arriving in the wrong order, and producing confusion that produces more confusing messages. We vow to notice dates on email.

2. Rick’s color monitor fails, and Rick is our webmaster (a single point failure). We talk back and forth for a week, and by then his monitor is fixed. We lose a week.

3. I forget to sign one of two signature lines on a bank form establishing the project bank account. This delays the payment of bills for 10 days, which might have caused rippling delays — but didn’t because people had their own budgets and could pay the bills and trust they would be reimbursed.

4. Kevin breaks his hand, which is especially tough because he can’t use his Braille reader. This delays lots of things Kevin is involved in, but the primary delay is in delivering his article for our pre-conference book. This turned out okay, because he wasn’t the only one whose article was delayed.

5. Dave, who is developing our wiki-web site, gets the flu. This delays the entire wiki testing for a couple of weeks, but it’s not yet on the critical path.

6. Some security certificates (whatever they are) expire on my browsers, and my attempt to update them crashes my system. This non-understood bug delays many tasks for several days (but the effect was somewhat ameliorated by having an alternative browser).

7. Several people take vacations they’ve been planning for a year or so (how inconsiderate of them!). This wouldn’t have been much of a problem if we’d thought to put these vacations in our plan.

8. Naomi has a serious family situation, so she decides she must cut back on her participation until it’s resolved. This adds extra load to several other people, but we were not overloaded, so the schedule effect is minimal once Johanna, our project manager, reallocates the tasks. We are able to reduce Naomi’s participation to the one area where her contribution is least replaceable, and we can do that because we know exactly what Naomi is best at (helping other writers).

9. People who were not at our initial planning meeting have to be brought up to date — not just on our plans, but on the logic behind our plans. We haven’t planned for this, so it’s a real delay — but has an excellent side effect of making us rethink some of our logic before it’s too late to change.

10. James joins the team and has to be brought up to speed. Again, more delay, but with the benefit that James is a talented tester, and subjects many of our plans to tests that we haven’t thought of. James is also an excellent writer/editor, and can take up some of Naomi’s tasks. So, we paid with some delay, and were repaid with some later catching up. In other words, educating James about the project turns out to be a sound investment. Late in the project, however, it wouldn’t have had time to pay off.

11. Our phone and email lists are somewhat out of date at the start of the project, causing irritating delays until we stop and fix it. This contact information should have been done at the very beginning, as it is a core competency for a distributed project. Also, we needed plans for updating this information, because the project is about a year long, and over that period of time, some contact information will undoubtedly change.

12. Marie’s son gets sick, which takes her attention away from AYE business for several weeks. I begin to wonder why all these people are being so inconsiderate of our conference’s problems!

13. I find a strange new mole on my neck, and have to have what the doctor calls minor surgery. (Minor surgery is surgery done to someone else.) Then she finds another suspicious mole, and I have more minor surgery. Then I have a dental emergency (I’ll spare you the painful details). I begin to understand why all these people are being so inconsiderate of our conference’s problems.

14. We are putting together a book of essays by the conference hosts, to introduce people to our work. By definition, we have to have an essay from every one of us, but a few people are at the tail end of the curve with respect to personal pictures, bios, and essays. There are a variety of fine reasons for their delays, but the fundamental reason this is so troublesome is the structure of that part of the project. Since everybody has to have an essay in the book, finishing is like trying to get that last Pokemon card, or last number for a bingo. The mathematics of this kind of requirement ensures that such a project will cause anguish, and we eventually decide to relax the requirement that everybody contribute. If a few are missing, we can live with that. Relaxing this requirement relaxes those of us who are responsible for the book sub-project — and curiously enough, seems to cause all the pictures, bios, and essays to arrive on time.

15. Unfortunately, some of the articles submitted aren’t up to quality standards we had set, and they have to be recycled. We could save quite a bit of time by lowering our quality standards, but we decide against this, since quality is one of the key goals of our conference. What good would it do, we reason, to preach quality when we ourselves don’t practice it.

16. There are lots of typos in the material we prepare for our web site (ayeconference.com), but unlike many web developers, we believed that web sites do have to be tested. Therefore, these delays were anticipated and planned for by the web and project teams, and so fit within the schedule.

17. From time to time, some team member panics about some item or another — which takes time and effort to soothe. Our perfectionism is a major cause of these panic attacks; satisficing (learning to think about what was acceptable quality, rather than perfect quality) is a major cure.

18. Then there are holidays, delaying things in a variety of ways. Why couldn’t Jesus have been born in August, we ask? Poor planning, we concluded — was it by God or by us? Probably us.

19. And of course there is bad weather, which turns out not to hurt us as much as we expected because our travel is mostly virtual. We are lucky there, because the infrequent travel is more by personal preference than project planning. Most of us travel much of the time, and we’ve learned Freedman’s First Law of Consulting: Don’t fly on the East Coast in Winter.

20. We are hurt much more when my ISP (Internet Service Provider) starts delaying delivery of my email by 1 to 7 days. We are hurt even more when Steve’s ISP, which hosted our email lists, starts failing intermittently. Once we realize what is going on, though, we are able to bypass the convenience of group lists and simply maintain our own teams’ lists until Steve gets things straightened out with his ISP. Steve eventually realizes, though, that he had chosen his ISP because they were the low-cost provider — a lesson for next time.

21. Then, once we have all the essays and bios and pictures, we realize that some people haven’t kept the paperwork concerning their articles that they had previously published elsewhere. As one contributor says, “It just didn’t seem important to keep those legal things — at the time.” Lesson obvious, and lesson learned — I hope.

Conclusions

Well, there are lots more than twenty-one, but I think I’ll stop here. Some of us will publish the entire project’s delay list in the future; it will probably be a book. And we’re planning to conduct a retrospective at the conference itself. For now, though, I think you might like to look over the list once more and compare some of your conclusions with mine.

God may have other priorities higher than your project. Leave some slack for Acts of God.

Perfectionism kills schedules; reasonableness saves them.

Certain project structures make success as likely as winning the lottery. Search out and eliminate this lottery effect from your project plan. Not only does this eliminate “bad luck,” but it also lowers psychological pressure on participants, which leads to “good luck.”

Quality is negotiable, but not infinitely negotiable.

Plans are predictions; plan to test them early and often, and then adjust them.

Machines fail. Software fails. People are even less perfect, but they’re more adaptable, so they’re handy to have around to back up the machine systems.

If you have a single point of failure, it will fail at a single point in time. After that, if you have any brains at all, you’ll remove it.

Cross-training is one of the surest ways to protect against those single points of failure. So is a good asset control system for all your project’s assets. If you fail to follow this system because “it doesn’t seem important,” you’re sure to lose your assets.

You won’t be aware in advance of all possible single points of failure, but if you do some risk analysis, you’ll be aware of many of them, which will leave you more time to deal with the ones you weren’t aware of.

You won’t appreciate other peoples’ delays until they happen to you, but try to learn to grant them a generous interpretation. This may calm you down sufficiently so that you can actually become part of the solution, rather than adding your blaming to the problem.

And, finally, I often hear my clients telling me that their project will make its schedule “if everything works out right.” Well, I’ve been in the project business for over forty years now, and I’ve seen several thousand projects. I’ve never seen one where “everything works out right.” This has led me to formulate Jerry’s Iron Rule of Project Life:

It Always Takes Longer

Defy this Iron Law at your peril. Plan for delays, and plan to be adaptable and forgiving when delays occur that aren’t part of your plan. You’ll be more successful, and you might even be happier. As of now, we’re on schedule for November, and we’re rather happy about it.

convert this post to pdf.

©2003 Gerald M. Weinberg, www.geraldmweinberg.com

People are always asking me to make predictions, especially predictions about their financial future. Which stocks will grow? Which dot.coms will fold? What jobs will be best? What should they study to prepare for their future jobs? Predictions are difficult. Well, actually predictions are easy – unless you want some accuracy. Since I’d feel responsible if I hurt somebody with a poor prediction, I seldom accept their invitation to predict.

Let me give some examples, starting with some predictions that, had I listened to them, would have seriously hurt my career as a writer. I have published about 40 successful books, yet I still don’t understand how publishers make predictions. The most successful of my books has been The Psychology of Computer Programming, which was delayed more than a year by a series of publishers who couldn’t decide what to do with it.

I first sent it to the company that had published all my previous books without hesitation. Here’s what they said: “It just is not worthwhile pushing this project any further. It may be that the concept is good … but the style and breadth of presentation is just not suitable. It could be that a major overhaul and rewrite will result in a marketable project. On the other hand, it may be wiser to forget the book concept entirely…”

The book was not overhauled, nor rewritten, but it was turned down by another publisher before it finally found a home. It’s now been in print for more than 30 years, and has sold over 100,000 copies in English, and many more in other languages. For the company that eventually published it, Psychology sold more copies and made more money than the next five books in their line. In retrospect, the two publishers who declined the project proved not to have much predictive power.

My second most successful book so far has been An Introduction to General Systems Thinking. Naturally, I sent this manuscript first to the perceptive publishers of Psychology. Here’s what they said: “Our referee believes that the market for such a volume is limited. With this in mind, I do not believe it is for us.” This one has been in print now for over 25 years, and has sold more than 50,000 copies.

The same pattern now holds for my third most successful book, The Secrets of Consulting, and the fourth, Are Your Lights On? – how to know what the problem really is, and the fifth, What Did You Say? – the art of giving and receiving feedback. And none of my less successful books, so far, have ever been turned down by publishers!

Experiences such as these have brought me to the reluctant conclusion that publishers know a lot about predicting the future success of a book – but what they know is exactly backwards. Or at least for new and different subjects. Shakespeare goes in and out of fashion, but even at low ebb sells pretty consistently. Algebra books compete with one another in a comfortable, steady market, as do introductory books in such subjects as economics, physics, philosophy. Books in such areas are more predictable, but, then, they’re less likely to make a big splash.

In computing, it’s not so steady, and predictions are even harder than with books. For publishers of computing books, the subject of tomorrow’s best-seller is unknown to today’s editor. Editors don’t follow the field; they follow the publications in the field. Unless and until somebody else publishes a book on the subject, the editor doesn’t consider it a subject at all. Those blinders are evident in the subjects of those books of mine that became the best sellers. Before the Psychology of Computer Programming appeared, the psychology of computer programming was not a subject.

Magazine and newspaper publishers have an easier time in a fast-moving field, because their publications generally get trashed before they become obsolete. Who reads last year’s Contract Professional to learn about the future of the job market?

But some of my friends do keep old copies of magazines, and I keep them if they contain an article of mine, so some evidence of successful or unsuccessful predictions remains for us to study. One of my friends sent me this prediction from Popular Science, May 1967, page 93:

“Timesharing, most experts agree, is the key to the computer’s future, at least for general use. A few years ago, when people thought about household computing at all, they thought of some small, inexpensive, individual unit that would keep track of the family checking account and automatically type out the Christmas card labels. Now we know it won’t be like that at all.

“The reason is economic. The bigger and faster the computer, the cheaper it makes each computation. Consequently, it will be far cheaper to build one monster computer with thousands of customers hooked to it than to have small, individual machines in individual homes.”

Here’s another prediction taken from the September, 1962 Datamation, which I happen to have because I had an article in it. (The article incidentally, was about how to make fake demonstrations, and that seems to be something we’re still doing 40 years later. Sound familiar?) Anyway, IBM’s 1962 recruiting ad said,

“IBM programmers … are devising programs that in turn use machine capability for formulating new programs. They are creating programs that enable computers to diagnose their own faults through self-checking. And they are helping to design the systems that will let scientists and engineers ‘talk’ to machines in the everyday language of science and engineering.”

I don’t know about you, but I hope they finish these projects before I retire. I so much want to talk to my computer in the everyday language of science and engineering. (Sound familiar?)

Patrick Henry once said, “I have but one lamp to guide my life. I only know the future from the past.” So, if the past can be used to make predictions, what predictions can we make using past predictions as a guide? Here are some that I’ve made, for myself:

1. Editors will predict what will be popular in the future. So will recruiters. They will be wrong.
2. People will predict that computers will get so cheap that programmers will be eliminated. They will be wrong.
3. People will predict that thinking and problem solving and other human activities will not be as important in the future as in the past. They will be wrong.
4. People will predict that there won’t be anything really new to do with computers (just Christmas-card labels and everyday language of science and engineering). They will be wrong.

So, here’s my advice for the future. Read some books, but not too many on one subject – and don’t take editors too seriously. Learn the most general of skills – how to think better and how to work with other people more effectively. Then look for jobs where you can apply those talents to build new things – but probably not things that are going to replace people. And, if you follow my predictions, you’ll probably have good jobs and good pay your whole life.

But I’m probably wrong.

convert this post to pdf.

© Gerald M. Weinberg, 2004 www.geraldmweinberg.com

Software Development Magazine recently interviewed Jerry. Here are some of his answers.

Q: What?s the most important piece of management-related advice anyone has ever given you?

GW: If you blame your employees, you’re a bad manager. You hired them, accepted them, supervised them, and directed their training. You?re responsible. If you don’t like what’s happening, look to your own behavior. But, if there’s credit to be given, it’s theirs.

Q: What about when a manager has been hired into a group where some or all employees were already hired by someone else?

GW: You don’t take a management job passively. Before you accept the position, you interview everyone in your group, and you get them to sign on with you, or you sign them off — or you don’t take the position. I don’t know why managers don’t understand that. They take on new assignments like high school kids on their first blind date.

Q: What if an employee begins to exhibit bad behavior after he or she has been hired — behavior that wasn’t apparent in the interview phase?

GW: Well, that happens, and that’s what managers get paid for handling. It can be a setback, but it’s your job to take care of it and get the job done. Unfortunately, not many technical managers have any preparation for this, something I’ve been trying to remedy for years — so in a sense, I’m to blame, because I’ve succeeded in only a few cases. Hey, if everything went smoothly all the time, you wouldn’t need managers.

Q: If you were to publish a third edition of The Psychology of Computer Programming, what new insights would it include? (Dorset House Publishing released a Silver Anniversary Edition in 1998.)

GW: I might add something about how to make yourself so valuable that your work will never be outsourced — something about the arrogance and overconfidence that has led to the loss of lots of software development jobs, not just to outsourcing, but to development work that’s just not being done because the odds of success are so poor.

Q: Is this bad behavior coming from the developers themselves, or do you mean to say the entire industry is to blame for not staying on top of innovation?

GW: It starts with the developers, and managers, too. But the overall result is, as you suggest, the entire industry getting too involved in navel-watching and competitiveness over the wrong values. For a long time, customers had nowhere else to go for service and had to put up with whatever we gave them. Now they have choices, and they’re getting even.

Q: In Are Your Lights On? (also available from Dorset House), you note that people like to complain. How do good managers draw the line between harmless venting and disruptive pessimism, if such a line needs to be drawn?

GW: “Drawing the line” is probably not the most useful metaphor. The approach I like most is to listen to the complaint for a reasonable amount of time, then say, “And what do you propose to do about this?” Depending on the reaction you get, take it from there.

Q: You once said, “If you can?t manage yourself, you have no business managing others.” Could you elaborate on that? What does it mean to manage one’s self?

GW: Well, perhaps you can look at Kipling’s famous poem,”If.” It starts:

If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too;
If you can wait and not be tired by waiting,
Or, being lied about, don’t deal in lies,
Or, being hated, don’t give way to hating,
And yet don’t look too good, nor talk too wise;

Most of this poem is still pretty good advice about what it means to manage yourself (except, unlike in Kipling’s day, it now applies to women, too).

Q: In your opinion, why do so many software projects go over budget or fail to meet their original requirements?

GW: There’s no single reason, but here are probably the top three:

1. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to speak truth to power.

2. The original budget, schedule and requirements were totally unrealistic, due to the inability of people to understand and acknowledge their own limitations (which we all have).

3. Even in those rare cases that people pass those first two hurdles, they lose emotional control during the project when something goes wrong — and something ALWAYS goes wrong. In 50 years, I’ve never seen a project where something didn’t go wrong. When it does, the project?s success is determined by the leaders’ ability to manage themselves emotionally.

Q: If you were to find yourself on a development team, reporting to a project manager, what qualities would you want that manager to have?

GW: I’d want that manager to be a congruent, adult human being, capable of learning from others and his or her own mistakes. A good place to start honing these attributes is the AYE Conference.

convert this post to pdf.

©2002 Gerald M. Weinberg, www.geraldmweinberg.com

On a typical day, I get 100-200 email messages, and some of my clients in large projects receive even more. Though emails improve my ability to communicate clearly and quickly, they may also prove a hindrance to certain kinds of communication. In particular, email does not adequately serve as a medium for recording an important agreement. An important email may be too transitory, too easily lost among volumes of less important communications, too easy to misunderstand, and too easily lead to unnecessary conflicts.

Although email can reduce the need for personal contact, it cannot entirely eliminate contact between teams building components that must work together to form a system. Separation of teams tends to create language differences that lead to misunderstood emails. Teams develop local goals that may diverge from project goals and actually conflict with other teams’ goals. With different language and divergent goals, interfaces stop being stable, clear, stakes in the ground. Instead, they can easily become the disputed border between two warring states or two different cultures. To prevent border wars, I prefer the ancient solution – writing and signing treaties.

A software treaty is more or less identical to a treaty between political units. I like my treaties to be written on a single piece of paper with a fancy border, like a gilt-edged stock certificate. A typical treaty might contain.

1. A reference to the technical terms being agreed to – such as a reference to a specific version of a document in the project’s repository.

2. A statement that all signatories agree to the technical terms in (1).

3. A statement that the treaty will remain in effect unless and until renegotiated among all the signatories.

4. Dated signatures of each team’s official representative – most often the team leader. The treaty implicitly recognizes the independence of the signatory teams and their ability to enter freely into agreements on technical matters.

5. (Possible) Management signatures witnessing the treaty.

Although a manager quite likely acts as facilitator to the negotiations, treaties will not work if parties are coerced into signing something they don’t understand, or don’t agree with. Nor will they work if some affected party fails to participate in the negotiations and sign the treaty, so management must ensure that all affected parties are represented.

After signing, however, good management becomes mandatory to enforce the pact the parties agreed upon. In other words, once each party freely gives its signature, the matter is no longer a purely technical one, but becomes political.

Why political? Because after the agreement, one party could disrupt the project and/or make the other party look very bad by covertly changing the agreement. A written treaty seals off this avenue for expressing any animosity or mistrust that exists between the parties. When people understand that management will rigorously enforce each treaty, they can quit bickering and get down to the business of building. Moreover, teams can work with the assurance that anything not in a treaty is not a commitment – and will not become a commitment without going through the treaty process.

With signed treaties covering all interfaces, no single team can disrupt the project by covertly changing the rules in the middle of the game. Woe to any team that fails to meet the interface specifications agreed upon in their treaties.

What happens if one party to the treaty decides they made a mistake, or got a poor deal? For instance, during the negotiations, I might have agreed to pass error-free data in return for two milliseconds more of execution time, but now I find that I cannot scrub the data that fast. I can then call for a renegotiation, but I may have to trade something else for the relief I seek – even something that will simplify my enemy’s job.

Such a concession may prove a bitter pill for me to swallow, especially as the renegotiation is done in front of management, but I have to understood that unilateral changes to my treaties will damage the project and make my life much less pleasant.

The startup of a treaty system will sometimes seem awkward, unfamiliar, and overly formal. I know from history, however, that this degree of formality is needed if former antagonists are to work together cooperatively. White ties are optional, however, and quite soon the awkwardness dissipates.

We frequently see one party resist actually signing a treaty, but such resistance always indicates that the resisting party is uncertain. Because the whole treaty process is designed to eliminate uncertainties, resistance tells me what I want to know that there is still more definitional work to be done.

Treaties are especially helpful for contractor professionals, who may rush into a poorly understood commitment in their eagerness to improve their cash flow. But no matter how much I hope that the definitional job is finished, the strong commitment implied by a signature prevents me from mistaking hope for reality.

By keeping communications on the level of reality, rather than hope, I may create a few problems today, but I avoid bigger problems tomorrow.

By making agreements between cooperating parties a strategy for peace, I avoid the hardest problems of all, the misunderstandings that lead to interpersonal conflicts.

convert this post to pdf.