Showing posts with label future. Show all posts
Showing posts with label future. Show all posts
Saturday, July 07, 2018
What were some jobs that existed 50 years ago but have largely disappeared today?
We often hear that we're in a time of change, but this observation isn't really news. We've been in a time of change for my whole lifetime, and well before that. Many jobs that once existed are no longer available, and many have even disappeared from memory.
We were challenged recently to recall some jobs that have disappeared in the past 50 years, and it was great fun reading all the answers, many of which described jobs I once held back in my youth. I go back a bit more than 50 years, though, so I have a few more to add.
The first, most obvious omission that popped into my mind was the iceman. In the 1930s, my family had an icebox (not a refrigerator, but an actual box that held a block of ice). The iceman’s horse-drawn wagon would come around and be surrounded by us kids, hoping to get free shards of ice caused when he cut up little blocks to fit our iceboxes.
Another job only briefly mentioned was typesetting. I never held that job, but I was trained for manual typesetting for a semester in high school. At least I know where terms like upper-case and lower-case come from.
Someone also mentioned keypunch operator, a task (not a job) that was often done by prisoners who were literally chained to their keypunch machines. What wasn't mentioned, however, were key verifier operators. Not many people today have ever seen a verifier machine, let alone even know what one was.
Even before my time, there were jobs that disappeared, but which I read about in a nineteenth century book about jobs for women. The final two chapters in the book were about a couple of sure-fire women’s jobs for the future (1900 was then the future).
First chapter was about telegraphoperators. The chapter “proved” that there was a great future for women because they could operate a telegraph key at least as fast as men (and the telephone had yet to be invented).
Second chapter was about picture tinters. There was, of course, no color photography, and it wasn’t really even conceived of. Women were supposedly much better at coloring photos because of their “artistic bent” and their more delicate hands. Though there are a few photo tinters still around today for special jobs, it’s not a career with a great future.
It's fun to think about these forgotten jobs, but they're also a source of important knowledge, or perhaps even wisdom. Job disappearance is not some new phenomenon caused by computers. It's always gone on through history. True, some jobs lasted a long time, so long that they were passed down from generation to generation, even becoming family names, such as Smith, Turner, Eisenhower, Baker, and Miller. (See, for example, <Meaning of Surnames> for hundreds of examples)
Some of those jobs still exist, though often modified by new technology. Do you still recognize Fuller, Chandler, or Ackerman? And many others have largely disappeared, remaining only in some special niche, like photo tinters. Do you know anybody named Armbruster who still makes crossbows? Well, you probably know a few Coopers, but how many of them still make barrels?
So, what's the lesson for your own future? If you're as old as I am, you probably don't have to worry about your job disappearing, but even my "job" as a writer is changing rapidly with new technology. Even if your type of job doesn't disappear entirely, you will be faced with changes.
I think your preparation for job changes will be the same as your preparation for changed jobs: increased adaptability. Today's market tends to reward specialization, but when you become totally specialized, you become the victim of change. Think what's happened to all those COBOL experts from a few years ago.
I'd suggest that you take advantage of the rewards of specialization but invest a small percentage of your time to learning something new. Always. Keep you mind flexible for a future none of us can predict.
p.s. Minutes after I posted this blog, several readers wrote:
Your first job, "computer" did also disappear. How long was that job around? (Kind of surprised you did not mention it in the blog post.)
----
Well, that's shows I'm a human being. What's that saying about shoemakers' children going barefuot? It never occurred to me to consider my 'computer' job as disappearing, but of course it has been largely taken over by machines. Thanks, readers.
Oh, and some more, including switchboard operator, another job I had.
Maybe you folks could add more via comments here.
Oh, and some more, including switchboard operator, another job I had.
Maybe you folks could add more via comments here.
Labels:
age,
art of change,
career,
computers,
future,
history of computers,
learning,
predicting
Wednesday, November 15, 2017
What's it like to rewrite a program from scratch?
This is an interesting question because so many programmers are so afraid of this task that they would never even ask it. Is this reluctance agile, or Agile?
But why would you want to do rewrite a program from scratch? The most important reason is to increase maintainability. In the initial writing, the focus is generally on merely getting the job done, without thinking of the program's future. Over their lifetime, many programs cost far more to maintain than to write originally, especially when the original program has become a thing of rags and patches.
A second, and often secondary reason to rewrite a program is efficiency. Newly constructed programs and highly patched old programs sometimes turn out to be slower than desired, but such inefficiency cannot erased by any amount of tweaking. Instead, increased efficiency requires a new approach, an approach that needs to be implemented from scratch.
But isn't rewriting expensive? Not usually. In fact, it’s generally far, far easier to rewrite a program from scratch than to write some brand-new program.
Why would a fresh start-over be cheaper than the original? Because in writing the original program, the original programmers answered so many difficult questions about what was really wanted. Requirements haven't changed, and most of the thought put into testing can be reused.
Those questions—requirements and test—usually make up more than half the total work put into a program. They have already been answered—but only if you resist the temptation to change those answers. If you don’t resist, then rewriting the program can be arbitrarily difficult.
I wish more programmers had to courage to rewrite some clumsy programs from scratch, rather than patch and patch and patch. And I wish their managers would encourage sensible rewriting, rather than force programmers to waste their skills, time, and energy keeping ancient programs on life support.
Wednesday, November 09, 2016
How do I choose the right career?
The question was, "How do I choose the right career?"
My answer was, "You can’t."
Other responders told you things about how to choose your right JOB, but a job is not a career. Maybe before the 21st century, the world of work was sufficiently stable that one could choose a career, but not longer.
For instance, I’m an old guy so I’ve had sort of a career—in computing. But back in the 1940s, when I asked this question, computers didn’t even exist. At least, none of my career counselors knew of them.
And even for the 20th century, I’ve had a rather stable career. My wife, on the other hand, started out to be a concert pianist, then became a musicologist, then a piano teacher, then an anthropologist, then a management consultant, then a world-class dog trainer, and right now is an animal behavior specialist. She works primarily with canines, but until she was 33 years old, she was deathly afraid of dogs.
In other words, don’t try to choose the right career, but prepare yourself for choosing many careers throughout your working life. Learn the fundamental skills that will serve you well in all your future careers, whatever you choose, whenever you choose them—people skills, problem solving, and systems thinking are what come to my mind as things you'd need in all careers.
That's why I've studied these things, teach them in workshops, and write books about them.
Sunday, January 15, 2012
Change Artist Challenge #12 Developing Yourself
A book (or a blog) can give you only what the author has to tell. But the learning that comes through self-knowledge has no limit. To learn through your own self-knowledge is to know how to listen, how to observe, and therefore you learn from everything: from music, from what people say and the way they say it, from anger, greed, ambition. - Jiddu Krishnamurti
The biggest benefit from change artistry comes when you start teaching other people to be change artists.
The Challenge
Your challenge is to make up a change artistry challenge of your own, one that will give you practice in an area you need most. Accept your own challenge and offer it to others.
Source
This is the last of the dozen challenges from Becoming a Change Artist. Additional exercises in the book may help you, but from now on, your job is to practice, practice, practice.
The biggest benefit from change artistry comes when you start teaching other people to be change artists.
The Challenge
Your challenge is to make up a change artistry challenge of your own, one that will give you practice in an area you need most. Accept your own challenge and offer it to others.
Source
This is the last of the dozen challenges from Becoming a Change Artist. Additional exercises in the book may help you, but from now on, your job is to practice, practice, practice.
Labels:
art of change,
books,
challenges,
change,
change artist,
future,
learning,
training
Monday, June 06, 2011
Beyond Agile Programming
After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. In order to contribute my bit to addressing that problem, I've posted this essay—one that's sure to infuriate many of my readers, including some of my best friends. So first let me tell you how it came about.
While reformatting my book, Rethinking Systems Analysis and Design for e-booking, I noticed a few places that might have needed updating to present realities. The version I was using was more than 20 years old, from just after the peak of excitement about "structured programming." In particular, there was a whole section entitled, "Beyond Structured Programming." As I contemplated updating that section, it dawned on me that I could almost update completely by substituting the name of any more recent "movement" (or fad) for the word "structured.
I also knew how smart most of my readers are, so I figured they would see the same possibility without my updating a thing. Instead of changing the book, I decided to update the section and publish it on this blog. Why? Because I think it shows an important pattern—a script where only the names have changed over at least five decades. So, here is the section with "agile" substituted for "structured," just as "structured" had been substituted for some other fad a generation earlier.
The Restructured Essay
Before I proceed further with the task of rethinking systems analysis and design, I'd like to express myself on the subject of another great "rethinking" in programming—the agile programming revolution. Although this essay was written a generation ago (now two generation), and the agile programming "revolution" is now an exhausted fad (for most programmers), most of what this essay says still applies—though to the next rethinking fad, and the next, and the next. I believe it will still apply long after I'm no longer writing new editions. Why? Because our industry seems to require a new fad every decade to keep itself from being bored. So, just apply the lessons to whatever fad happens to be dominating the computer press at the time you're reading this.
Before anyone becomes overly enthusiastic about what the rest of this book says, I want to take stock of what this great agile rethinking has done. I don't claim to be starting a new revolution of the magnitude most of the fads claim, so I'd like people to realize how slow and how small the agile programming movement has been, in case they think this book is going to make much difference.
My own personal stock-taking on the subject of agile programming is based on visits to some forty installations on two continents over the past ten years, plus a few hundred formal and informal discussions with programmers, analysts, managers, and users during the same period. Because of the conditions under which these visits and interviews took place, I would estimate the sample is quite heavily biased toward the more progressive organizations. By "progressive," I mean those organizations more likely to:
• Send staff to courses
• Hire outside consultants, other than in panic mode
• Encourage staff to belong to professional organizations, and to attend their meetings.
Consequently, my stock-taking is likely to be rather optimistic about the scope and quality of the effects of agile programming.
The first conclusion I can draw from my data is this:
Much less has been done than the press would have you believe.
I interpret the word "press" very loosely, including such sources as:
• Enthusiastic upper management
• The trade press
• The vendors and their advertising agencies
• The universities, their public relations staffs, and their journals
• The consulting trade.
Although this may be the most controversial of my observations, it is the most easily verified. All you need do is ask for examples of agile programming—not anecdotes, but actual examples of agile behavior and agile-produced code. If you're given any examples at all, you can peruse them for evidence of following the "rules" of agile programming. Generally, you will find:
a. Five percent can he considered thoroughly agile.
b. Twenty percent can be considered to follow agile practices sufficiently to represent an improvement over the average code of 1990.
c. Fifty percent will show some evidence of some attempt to follow some "agile rules," but without understanding and with little, if any, success.
d. Twenty-five percent will show no evidence of influence by any ideas about programming (not just agile) from the past twenty years.
Please remember: these percentages apply to the code and behavior you will actually see in response to your request. If you ask software organizations at random for "agile examples," about two-thirds will manage to avoid giving you anything. We can merely speculate what they do, and what their code contains.
My second conclusion:
There are rather many conceptions of what agile programming ought to look like, all of which are reasonably equivalent if followed consistently.
The operative clause in this observation seems to be "if followed consistently." Some of these conceptions are marketed in books and/or training courses. Some are purely local to a single installation, or even to one team in an installation. Most are mixtures of some "patented" method and local adaptations.
My third observation:
Methods representing thoughtful adaptations of "patented" and "local" ideas on agile programming are far more likely to be followed consistently.
In other words, programmers seem disinclined to follow an agile methodology when it is either:
1. Blind following of "universal rules"
2. Blind devotion to the concept: anything "not invented here" must be worthless.
My fourth observation:
I have other observations to make, but now I must pause and relate the effect these observations have on many readers, perhaps including you. I recall a story about a little boy who was playing in the schoolyard rather late one evening. A teacher who had been working late noticed the boy and asked if he knew what time it was.
"I'm not sure," the boy said, "but I know it isn't six o'clock yet."
"And how do you know that?" the teacher asked.
"Because I'm supposed to be home at six, and I'm not home."
When I make my first three observations about agile programming, I have a similar reaction—something like this:
"These can't be right, because if they were right, why would there be so much attention to agile programming?"
In spite of its naive tone, the question deserves answering. The answer can serve as my fourth observation:
Agile programming has received so much attention for the following reasons:
• The need is very great for some help in programming.
• To people who don't understand programming at all, it seems chaotic, so the term "agile" sounds awfully promising.
• The approach actually works, when it is successfully applied, so there are many people willing to give testimonials, even though their percentages among all programmers may not be great.
• The computer business has always been driven by marketing forces, and marketing forces are paid to be optimistic, and not to distinguish between an idea and its practical realization.
In other words, the phrase "agile programming" is similar to the phrase"our latest computer," because each phrase can be used interchangeably in statements such as these:
• "If you are having problems in information processing, you can solve them by installing our latest computer."
• "Our latest computer is more cost effective and easier to use."
• "Your people will love our latest computer, although you won't need so many people once our latest computer has been installed."
• Conversion? No problem! With our latest computer, you'll start to realize savings in a few weeks, at most."
So actually, the whole agile programming pitch was pre-adapted for the ease of professionals, who have always believed "problems" had "solutions" which could be mechanically applied.
My final observation is related to all of the others:
Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don't buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they're applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.
There's yet another lesson in all this that's much bigger than agile programming or any new hardware or software or process:
Our profession contains few, if any, easy solutions. Success in problem solving comes to those who don't put much faith in the latest "magic," but who are willing to try ideas out for themselves, even when those ideas are presented in a carnival of public relations blather.
Based on this lesson, I'd like to propose a new "programming religion," a religion based on the following articles of faith:
• There's no consistent substitute for a thorough understanding of your problem, though sometimes people get lucky.
• There's no solution applicable to every problem, and what may be the best approach in one circumstance may be precisely the worst in another.
• There are many useful approaches applicable to more than one problem, so it pays to become familiar with what has worked before.
• The trick to problem solving is not just "know-how," but "know-when"—which lets you adapt the solution method to the problem, and not vice versa.
• No matter how much you know how or know when, some problems won't yield to present knowledge, and some aspects of the problem nobody currently understands, so humility is always in order.
I realize writing a book is not the most humble thing a person can do, but it's what I do best, and how I earn my living. I'd be embarrassed if anyone took this book too seriously. We don't need another "movement" just now, unless it is something analogous to a bowel movement—something to flush our system clean of waste material we've accumulated over the years.
Where to read the original
If you want to check on my historical work, you can find the original essay (and many others) in Rethinking Systems Analysis and Design, which is an ebook on Smashwords (where you can probably see it in the free sample) and Kindle and Barnes and Noble.
Problem-Solving Leadership Workshop
Reminder: The second (and last) PSL Workshop for 2011 will take place in Albuquerque, New Mexico, USA, August 28-September 2, 2011. Only a few places left for participants, so for more information, see <http://www.estherderby.com/workshops/problem-solving-leadership-psl http://www.estherderby.com/workshops/problem-solving-leadership-psl>
While reformatting my book, Rethinking Systems Analysis and Design for e-booking, I noticed a few places that might have needed updating to present realities. The version I was using was more than 20 years old, from just after the peak of excitement about "structured programming." In particular, there was a whole section entitled, "Beyond Structured Programming." As I contemplated updating that section, it dawned on me that I could almost update completely by substituting the name of any more recent "movement" (or fad) for the word "structured.
I also knew how smart most of my readers are, so I figured they would see the same possibility without my updating a thing. Instead of changing the book, I decided to update the section and publish it on this blog. Why? Because I think it shows an important pattern—a script where only the names have changed over at least five decades. So, here is the section with "agile" substituted for "structured," just as "structured" had been substituted for some other fad a generation earlier.
The Restructured Essay
Before I proceed further with the task of rethinking systems analysis and design, I'd like to express myself on the subject of another great "rethinking" in programming—the agile programming revolution. Although this essay was written a generation ago (now two generation), and the agile programming "revolution" is now an exhausted fad (for most programmers), most of what this essay says still applies—though to the next rethinking fad, and the next, and the next. I believe it will still apply long after I'm no longer writing new editions. Why? Because our industry seems to require a new fad every decade to keep itself from being bored. So, just apply the lessons to whatever fad happens to be dominating the computer press at the time you're reading this.
Before anyone becomes overly enthusiastic about what the rest of this book says, I want to take stock of what this great agile rethinking has done. I don't claim to be starting a new revolution of the magnitude most of the fads claim, so I'd like people to realize how slow and how small the agile programming movement has been, in case they think this book is going to make much difference.
My own personal stock-taking on the subject of agile programming is based on visits to some forty installations on two continents over the past ten years, plus a few hundred formal and informal discussions with programmers, analysts, managers, and users during the same period. Because of the conditions under which these visits and interviews took place, I would estimate the sample is quite heavily biased toward the more progressive organizations. By "progressive," I mean those organizations more likely to:
• Send staff to courses
• Hire outside consultants, other than in panic mode
• Encourage staff to belong to professional organizations, and to attend their meetings.
Consequently, my stock-taking is likely to be rather optimistic about the scope and quality of the effects of agile programming.
The first conclusion I can draw from my data is this:
Much less has been done than the press would have you believe.
I interpret the word "press" very loosely, including such sources as:
• Enthusiastic upper management
• The trade press
• The vendors and their advertising agencies
• The universities, their public relations staffs, and their journals
• The consulting trade.
Although this may be the most controversial of my observations, it is the most easily verified. All you need do is ask for examples of agile programming—not anecdotes, but actual examples of agile behavior and agile-produced code. If you're given any examples at all, you can peruse them for evidence of following the "rules" of agile programming. Generally, you will find:
a. Five percent can he considered thoroughly agile.
b. Twenty percent can be considered to follow agile practices sufficiently to represent an improvement over the average code of 1990.
c. Fifty percent will show some evidence of some attempt to follow some "agile rules," but without understanding and with little, if any, success.
d. Twenty-five percent will show no evidence of influence by any ideas about programming (not just agile) from the past twenty years.
Please remember: these percentages apply to the code and behavior you will actually see in response to your request. If you ask software organizations at random for "agile examples," about two-thirds will manage to avoid giving you anything. We can merely speculate what they do, and what their code contains.
My second conclusion:
There are rather many conceptions of what agile programming ought to look like, all of which are reasonably equivalent if followed consistently.
The operative clause in this observation seems to be "if followed consistently." Some of these conceptions are marketed in books and/or training courses. Some are purely local to a single installation, or even to one team in an installation. Most are mixtures of some "patented" method and local adaptations.
My third observation:
Methods representing thoughtful adaptations of "patented" and "local" ideas on agile programming are far more likely to be followed consistently.
In other words, programmers seem disinclined to follow an agile methodology when it is either:
1. Blind following of "universal rules"
2. Blind devotion to the concept: anything "not invented here" must be worthless.
My fourth observation:
I have other observations to make, but now I must pause and relate the effect these observations have on many readers, perhaps including you. I recall a story about a little boy who was playing in the schoolyard rather late one evening. A teacher who had been working late noticed the boy and asked if he knew what time it was.
"I'm not sure," the boy said, "but I know it isn't six o'clock yet."
"And how do you know that?" the teacher asked.
"Because I'm supposed to be home at six, and I'm not home."
When I make my first three observations about agile programming, I have a similar reaction—something like this:
"These can't be right, because if they were right, why would there be so much attention to agile programming?"
In spite of its naive tone, the question deserves answering. The answer can serve as my fourth observation:
Agile programming has received so much attention for the following reasons:
• The need is very great for some help in programming.
• To people who don't understand programming at all, it seems chaotic, so the term "agile" sounds awfully promising.
• The approach actually works, when it is successfully applied, so there are many people willing to give testimonials, even though their percentages among all programmers may not be great.
• The computer business has always been driven by marketing forces, and marketing forces are paid to be optimistic, and not to distinguish between an idea and its practical realization.
In other words, the phrase "agile programming" is similar to the phrase"our latest computer," because each phrase can be used interchangeably in statements such as these:
• "If you are having problems in information processing, you can solve them by installing our latest computer."
• "Our latest computer is more cost effective and easier to use."
• "Your people will love our latest computer, although you won't need so many people once our latest computer has been installed."
• Conversion? No problem! With our latest computer, you'll start to realize savings in a few weeks, at most."
So actually, the whole agile programming pitch was pre-adapted for the ease of professionals, who have always believed "problems" had "solutions" which could be mechanically applied.
My final observation is related to all of the others:
Those installations and individuals who have successfully realized the promised benefits of agile programming tend to be the ones who don't buy the typical hardware or software pitch, but who listen to the pitch and extract what they decide they need for solving their problems. They do their own thinking, which includes using the thoughts of others, if they're applicable. By and large, they were the most successful problem solvers before agile programming, and are now even more successful.
There's yet another lesson in all this that's much bigger than agile programming or any new hardware or software or process:
Our profession contains few, if any, easy solutions. Success in problem solving comes to those who don't put much faith in the latest "magic," but who are willing to try ideas out for themselves, even when those ideas are presented in a carnival of public relations blather.
Based on this lesson, I'd like to propose a new "programming religion," a religion based on the following articles of faith:
• There's no consistent substitute for a thorough understanding of your problem, though sometimes people get lucky.
• There's no solution applicable to every problem, and what may be the best approach in one circumstance may be precisely the worst in another.
• There are many useful approaches applicable to more than one problem, so it pays to become familiar with what has worked before.
• The trick to problem solving is not just "know-how," but "know-when"—which lets you adapt the solution method to the problem, and not vice versa.
• No matter how much you know how or know when, some problems won't yield to present knowledge, and some aspects of the problem nobody currently understands, so humility is always in order.
I realize writing a book is not the most humble thing a person can do, but it's what I do best, and how I earn my living. I'd be embarrassed if anyone took this book too seriously. We don't need another "movement" just now, unless it is something analogous to a bowel movement—something to flush our system clean of waste material we've accumulated over the years.
Where to read the original
If you want to check on my historical work, you can find the original essay (and many others) in Rethinking Systems Analysis and Design, which is an ebook on Smashwords (where you can probably see it in the free sample) and Kindle and Barnes and Noble.
Problem-Solving Leadership Workshop
Reminder: The second (and last) PSL Workshop for 2011 will take place in Albuquerque, New Mexico, USA, August 28-September 2, 2011. Only a few places left for participants, so for more information, see <http://www.estherderby.com/workshops/problem-solving-leadership-psl http://www.estherderby.com/workshops/problem-solving-leadership-psl>
Labels:
Agile,
change artist,
future,
history,
methodology,
remembering
Sunday, June 14, 2009
Was There Process Before Agile?
Reader June Kim recently wrote:
On p.328 of Volume 4 of your Quality Software Management series, the first line goes:
"Here's another example, mixing incremental development and hacking:"
In this Chapter 18, the process models you mention and describe are Waterfall, Cascade, Iterative Enhancement, and Prototyping (with Hacking and Rapid Prototyping as its variants). There isn't incremental development.
"incremental development" as you wrote on that page, doesn't appear before that line in the chapter.
Is it one among the four process models that you mentioned earlier in the chapter, or Is it something different?
ANSWER: First, you have to remember that when QSM was written, there was no "Agile" development craze. We were doing various development process, some of which were given capital letters, some which were not, and some which were "owned" by certain advocates. I was trying to be descriptive then, not favor anybody's pet process.
There were some "owned" processes (using the hated word, "methodology," and charging tens of thousands of dollars for shelves full of notebooks which nobody read). I suppose some of them are still around, but most of the organizations I work with are now smarter than to fall for that fallacy. For the most part, every organization custom-tailored its own process (or, in most cases, processes, plural).
Of course, that's still true today. I don't find many organizations using some "pure" version of agile.
ANSWER: Historically, the people who first named "Agile" processes were borrowing the best of all these methods. You could also say that any agile process is a cascade (or iterative enhancement if you're actually putting each iteration's output into use). Agile is much more than these processes, making explicit many team practices to support the iterative nature of the development.
ANSWER: That's always the case, no matter what the method, if the customer is reluctant to participate. (Until the end, when they whine, "But that's not what we wanted.")
QUESTION: What could you do in this case? Drop Agile process?
ANSWER: It's not an Agile process if the customer (or surrogate) isn't participating. In fact, I would drop any customer who doesn't participate. That's the rule I use in all my consulting, too. I don't believe you can help people who aren't willing to help themselves.
QUESTION: Or, make the customer be the part of the process? Then how? This is still a hard question to me, even with 10 years of experience in agile.
ANSWER: It's definitely one of the hardest questions with Agile or any method. Hard for most technical leaders because they lack the training and skills to work with reluctant customers.
So, I train them in these skills (a major goal of the AYE Conference and the PSL workshop), but primarily everything starts by simply pausing the work unless and until the customer has been identified and persuaded to participate.
On p.328 of Volume 4 of your Quality Software Management series, the first line goes:
"Here's another example, mixing incremental development and hacking:"
In this Chapter 18, the process models you mention and describe are Waterfall, Cascade, Iterative Enhancement, and Prototyping (with Hacking and Rapid Prototyping as its variants). There isn't incremental development.
"incremental development" as you wrote on that page, doesn't appear before that line in the chapter.
Is Agile An Example of Incremental Development?
QUESTION: Which process model are you referring to when you wrote "incremental development"?Is it one among the four process models that you mentioned earlier in the chapter, or Is it something different?
ANSWER: First, you have to remember that when QSM was written, there was no "Agile" development craze. We were doing various development process, some of which were given capital letters, some which were not, and some which were "owned" by certain advocates. I was trying to be descriptive then, not favor anybody's pet process.
There were some "owned" processes (using the hated word, "methodology," and charging tens of thousands of dollars for shelves full of notebooks which nobody read). I suppose some of them are still around, but most of the organizations I work with are now smarter than to fall for that fallacy. For the most part, every organization custom-tailored its own process (or, in most cases, processes, plural).
Of course, that's still true today. I don't find many organizations using some "pure" version of agile.
Where Do You Place Agile?
QUESTION: I am interested where you would put Agile process. I think Agile(XP and Scrum, for example) is closest to Rapid Prototyping as you described.ANSWER: Historically, the people who first named "Agile" processes were borrowing the best of all these methods. You could also say that any agile process is a cascade (or iterative enhancement if you're actually putting each iteration's output into use). Agile is much more than these processes, making explicit many team practices to support the iterative nature of the development.
What Happens When the Customer Won't Participate?
QUESTION: If so, it has the same danger when the customer isn't willing to be the integral part of the process.ANSWER: That's always the case, no matter what the method, if the customer is reluctant to participate. (Until the end, when they whine, "But that's not what we wanted.")
QUESTION: What could you do in this case? Drop Agile process?
ANSWER: It's not an Agile process if the customer (or surrogate) isn't participating. In fact, I would drop any customer who doesn't participate. That's the rule I use in all my consulting, too. I don't believe you can help people who aren't willing to help themselves.
QUESTION: Or, make the customer be the part of the process? Then how? This is still a hard question to me, even with 10 years of experience in agile.
ANSWER: It's definitely one of the hardest questions with Agile or any method. Hard for most technical leaders because they lack the training and skills to work with reluctant customers.
So, I train them in these skills (a major goal of the AYE Conference and the PSL workshop), but primarily everything starts by simply pausing the work unless and until the customer has been identified and persuaded to participate.
Labels:
Agile,
future,
history,
methodology,
process
Saturday, February 07, 2009
Estimating (continued)
Back on April 17, 2006, I posted an entry called "Estimating Projects: A History of Failure." I try to make entries that are not ephemeral, so I'm happy to see that people are still commenting on this one almost three years later. I'm suggesting here that you go back on the blog and read the latest comment, from "Will."
Will has many wise things to say about how to do, and not do, estimating. Will, if you're writing a book on project management, give us the title, publisher, and estimated date we can expect to see it.
Take a look, and if you have comments, add them here.
Will has many wise things to say about how to do, and not do, estimating. Will, if you're writing a book on project management, give us the title, publisher, and estimated date we can expect to see it.
Take a look, and if you have comments, add them here.
Labels:
estimating,
future,
predicting
Tuesday, April 15, 2008
The Consultant's Money-Back Guarantee
On LinkIn, recently there was a question about what a client had to do to hire a consultant who wouldn't rip them off, just taking money for no measurable result. In my response to the question, I wrote:
I make this easy for my clients by two principles of my consulting business:
1. At the end of every consulting visit, I ask them to evaluate the worth of my contribution. If it's not worth more than they paid me, we either adjust what I'm doing or we terminate the relationship.
2. If they don't feel what I've done is worth what they've paid, they can have their money back, no questions asked. I make sure they know this up front--though I've never had to give back their money.
If a consultant doesn't give you both these things, don't hire them.
While anything that any human does is a heuristic, why should a consultant want to give back the money for the client not happy with what the consultant influenced?
For instance, I go in as a Consultant to solve a problem. At the end I help the client understand that there is more investment he ought to do in order to ship the product. The client feels unhappy because he hired me thinking that I would help him ship the product with existing budget.
Maybe what I did is what other good consultants might have done, so should I return his money back because he feels disappointed?
Why? Because it's your job to satisfy the client. That's what they pay you for. If you buy a laptop from Apple or Dell or HP and when you try to use it, it doesn't work, don't you expect to get your money back? If you don't, would you ever buy a computer from Apple or Dell or HP again? So, one reason to offer a money-back guarantee is to develop future business with that client.
Another reason is to keep that client from spreading bad news about you to 16 other potential clients. (That's what people do when they feel they were cheated by a vendor. When they feel they got a good value, they tend to tell only three other people.)
Would you drive a car without a steering wheel and brakes? Then why would you want to take on a consulting assignment without them?
I guess maybe you wouldn't want them if all you wanted was a runaway car, one that somehow kept paying you as it careened away toward a fatal crash. If cash flow is the only reason someone is in the consulting business, I hope they hit that wall as soon as possible. People like that give my profession a bad name, and thereby hurt a great many ethical and effective consultants.
Don't get me wrong. I think money is a fine reason for being a consultant, but not if it's the only reason. I want to get paid for my work, but only if I'm actually helping people. I don't want to be a fraud.
Pradeep goes on to say: I think such traps have to be cleared before a Consultant gets in by asking questions like, "What value means to you?" and "Can you think of things that you'd be disappointed to know at the end of this assignment?" and "Do you have insight about any kind of information that could cause you nightmares?"
Well, yes, of course you want to clear this up before you go in, but that's not always possible. People often don't know in advance what they want. They only know when they see it. Many of my clients ask for one thing when I come in, but through my consulting learn that they really wanted something else that was more valuable.
To take an extreme case, at one client, the man who invited me in to help with strategic planning learned that his alcoholism was tearing his own organization apart, and what he needed to do was fire himself and go into treatment. That wasn't what he asked for at the beginning of the assignment, but by the end, he knew that this result was far, far more valuable. I asked him if he wanted his money back (he was part owner of the company) and he said no. In fact, he wanted to pay me more--but I refused. I did my job (helping his company improve), and I earned my pay. That was enough for me.
Not every consultant would want to return back the money and that could be a good marketing stint or building credibility or a distinguishing factor but if every consultant does that ( which is not an easy thing ) then it might end up causing confusion of whom to pick.
Pradeep is right. It's not an easy thing. In fact, it's so unlikely that it's not worth worrying about.
But, if a lot of consultants used these principles, maybe there wouldn't be so many derogatory jokes about our profession of consulting.
An intelligent client picks an intelligent consultant and that's a heuristic, too.
Well, yes, that's certainly a heuristic, and a necessary one. But not by any means a sufficient one. Intelligence without ethics is like a biological weapon in the hands of a terrorist. Very powerful, to be sure, but you'd much rather not have it on your premises.
I make this easy for my clients by two principles of my consulting business:
1. At the end of every consulting visit, I ask them to evaluate the worth of my contribution. If it's not worth more than they paid me, we either adjust what I'm doing or we terminate the relationship.
2. If they don't feel what I've done is worth what they've paid, they can have their money back, no questions asked. I make sure they know this up front--though I've never had to give back their money.
If a consultant doesn't give you both these things, don't hire them.
Why Give Their Money Back?
Pradeep Soundararajan wrote, in response:While anything that any human does is a heuristic, why should a consultant want to give back the money for the client not happy with what the consultant influenced?
For instance, I go in as a Consultant to solve a problem. At the end I help the client understand that there is more investment he ought to do in order to ship the product. The client feels unhappy because he hired me thinking that I would help him ship the product with existing budget.
Maybe what I did is what other good consultants might have done, so should I return his money back because he feels disappointed?
Why? Because it's your job to satisfy the client. That's what they pay you for. If you buy a laptop from Apple or Dell or HP and when you try to use it, it doesn't work, don't you expect to get your money back? If you don't, would you ever buy a computer from Apple or Dell or HP again? So, one reason to offer a money-back guarantee is to develop future business with that client.
Another reason is to keep that client from spreading bad news about you to 16 other potential clients. (That's what people do when they feel they were cheated by a vendor. When they feel they got a good value, they tend to tell only three other people.)
The Steering Wheel and Brakes
For my consulting assignments, this guarantee acts like a combination of steering wheel and brakes. It guarantees that the client and I will pause periodically and see if we're going in the right direction. If we're not, we can use the steering wheel to change course, or in extreme cases, just apply the brakes and end the assignment.Would you drive a car without a steering wheel and brakes? Then why would you want to take on a consulting assignment without them?
I guess maybe you wouldn't want them if all you wanted was a runaway car, one that somehow kept paying you as it careened away toward a fatal crash. If cash flow is the only reason someone is in the consulting business, I hope they hit that wall as soon as possible. People like that give my profession a bad name, and thereby hurt a great many ethical and effective consultants.
Don't get me wrong. I think money is a fine reason for being a consultant, but not if it's the only reason. I want to get paid for my work, but only if I'm actually helping people. I don't want to be a fraud.
What Is Value?
But perhaps the most important reason to offer this guarantee is to force them, and you, to think about what value means to each of you.Pradeep goes on to say: I think such traps have to be cleared before a Consultant gets in by asking questions like, "What value means to you?" and "Can you think of things that you'd be disappointed to know at the end of this assignment?" and "Do you have insight about any kind of information that could cause you nightmares?"
Well, yes, of course you want to clear this up before you go in, but that's not always possible. People often don't know in advance what they want. They only know when they see it. Many of my clients ask for one thing when I come in, but through my consulting learn that they really wanted something else that was more valuable.
To take an extreme case, at one client, the man who invited me in to help with strategic planning learned that his alcoholism was tearing his own organization apart, and what he needed to do was fire himself and go into treatment. That wasn't what he asked for at the beginning of the assignment, but by the end, he knew that this result was far, far more valuable. I asked him if he wanted his money back (he was part owner of the company) and he said no. In fact, he wanted to pay me more--but I refused. I did my job (helping his company improve), and I earned my pay. That was enough for me.
What If Every Consultant Did This?
Pradeep then says:Not every consultant would want to return back the money and that could be a good marketing stint or building credibility or a distinguishing factor but if every consultant does that ( which is not an easy thing ) then it might end up causing confusion of whom to pick.
Pradeep is right. It's not an easy thing. In fact, it's so unlikely that it's not worth worrying about.
But, if a lot of consultants used these principles, maybe there wouldn't be so many derogatory jokes about our profession of consulting.
Intelligence Isn't Enough
Pradeep then concludes:An intelligent client picks an intelligent consultant and that's a heuristic, too.
Well, yes, that's certainly a heuristic, and a necessary one. But not by any means a sufficient one. Intelligence without ethics is like a biological weapon in the hands of a terrorist. Very powerful, to be sure, but you'd much rather not have it on your premises.
Labels:
alcoholism,
congruence,
consulting,
ethics,
future,
money
Thursday, November 22, 2007
My Career, An Interview
Magnus Ljadas has just published an interview with me on the Citerus (Sweden) website (www.citerus.se).
I've been interviewed many times over the years, but Magnus is the best interviewer I can remember. I hope it's as fun and informative for you to read as it was for me to write.
http://www.citerus.se/kunskap/pnehm/pnehmartiklar/interviewwithjerryweinberg.5.484cc23b1165f30e75680002483.html
Or you can use tiny url = <http://tinyurl.com/2tro4f>
I've been interviewed many times over the years, but Magnus is the best interviewer I can remember. I hope it's as fun and informative for you to read as it was for me to write.
http://www.citerus.se/kunskap/pnehm/pnehmartiklar/interviewwithjerryweinberg.5.484cc23b1165f30e75680002483.html
Or you can use tiny url = <http://tinyurl.com/2tro4f>
Labels:
career,
consulting,
future,
motivation,
training
Monday, June 18, 2007
How Good Are Expert Predictions?
Magazines are ephemeral, but some of my friends compulsively keep stacks of copies of old magazines. I've always wondered what possible use these collections can be, but here's a lovely contribution one of my readers sent, taken from Popular Science of May, 1967, page 93.
"Time sharing, 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 computers at all, they though of some small, inexpensive, individual unit that would keep track of the family checking account and automatically type of 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 or even millions of customers hooked into it than to have small, individual machines in individual homes."
Now we know that "most experts" were wrong: we know it would be like that, because today, 40 years later, it is like that. I was something of an "expert" in 1967, and I'm proud to say that I wasn't one of those who made such a piss-poor prediction. That's probably because I don't make predictions—except the prediction that almost all of the predictions we make today will turn out to be piss-poor 40 years later.
Why do I make such a meta-prediction? Well, I've researched the past, and, as Patrick Henry said, "I only know the future from the past." But don't take Patrick's or my word for it. Here's how you can find out for yourself. Beg, borrow, or steal a copy of some old computer magazine. Spend as much time reading it as you typically spend on this month's issue of the same publication (or an equivalent one, if the old one is no longer around). I guarantee that the time spent on the old one will be more productive.
Because I was an "expert" in the 1960s, I published a number of articles in the leading computer magazine of the time, Datamation.. I do save my old articles, so I happen to have a copy of Datamation. from September, 1962. My article in that issue is entitled, "How to Automate Demonstrations."
Although the print magazine Datamation. itself shuffled off this mortal coil in 1997, I'm proud to say that my 1962 article would stand up pretty well even today. Perhaps even better today. Now that hardly any part of the computer moves, demonstrations are much more challenging to create. Of course, this was supposed to be a humorous article, though not everyone realized it at the time. I received a dozen requests for the Demonstration Compiler—that is, the compiler that compiled fake demonstrations. (Hmm, is there any other kind?)
On page 79 of that issue of Datamation., there's an advertisement from Computer Dynamics of Silver Spring, Maryland. (What ever happened to them.?
"MEMO Re: COMPUTER TIME
Solve your computer problems efficiently and economically by using our 32K, 10 tape IBM 7090 at 450ドル per hour." (That's about 5,000ドル per hour or more in today's dollars.)
Today, 45 years later, I own five computers, each of which is far more powerful than that 7090. As far as their value, I've thrown away a more computing power than that because nobody wanted it. Yes, the ten tape drives would still be a bit expensive today, but why would I want them? I own more than a dozen disk drives, each of which stores far more than those ten tapes.
The list of advertisers from that issue contains many forgotten names of companies selling computers, plus a few companies that are still around but no longer selling computers. Here's some examples:
PHILCO "Philco's on the move."
RCA "What's new at RCA is news in EDP."
GENERAL PRECISION (Surely everyone remembers the RPC-4000.)
ASI "More computation per dollar—on the ASI-210."
GENERAL ELECTRIC "Progress is our most important product."
FRIDEN "This is Practimation."
AUTONETICS "It's called RECOMP III."
TRW "Be operational now with the TRW-130 (AN/UYK-1)"
BENDIX "Is your programming career in a closed loop?"
Bendix didn't actually advertise their machine (no, it wasn't a washing machine), but they were crying out for programmers. And so were most of the others, "from 7,000ドル on up."
Even IBM (who, at last look, was still around), was desperate for programmers to "shape the future of a new technology." Sound familiar? Although machines are millions of times faster and cheaper, some things—human things, mostly—don't seem to change in 45 years:
"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."
Gee, I hope they finish these projects soon. I've been waiting a long time to talk to my computers.
Perhaps, in the end, all this flux of companies and jargon and sales promises is merely an illusion. Perhaps it's what doesn't change that teaches us the most important things about ourselves.
And what is it that doesn't change?
Us.
Oh, the faces change. The names change. But the behavior, the hopes, the visions, the gullibility—they don't change. Maybe that's a prediction you can safely make.
"Time sharing, 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 computers at all, they though of some small, inexpensive, individual unit that would keep track of the family checking account and automatically type of 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 or even millions of customers hooked into it than to have small, individual machines in individual homes."
Now we know that "most experts" were wrong: we know it would be like that, because today, 40 years later, it is like that. I was something of an "expert" in 1967, and I'm proud to say that I wasn't one of those who made such a piss-poor prediction. That's probably because I don't make predictions—except the prediction that almost all of the predictions we make today will turn out to be piss-poor 40 years later.
Why do I make such a meta-prediction? Well, I've researched the past, and, as Patrick Henry said, "I only know the future from the past." But don't take Patrick's or my word for it. Here's how you can find out for yourself. Beg, borrow, or steal a copy of some old computer magazine. Spend as much time reading it as you typically spend on this month's issue of the same publication (or an equivalent one, if the old one is no longer around). I guarantee that the time spent on the old one will be more productive.
Because I was an "expert" in the 1960s, I published a number of articles in the leading computer magazine of the time, Datamation.. I do save my old articles, so I happen to have a copy of Datamation. from September, 1962. My article in that issue is entitled, "How to Automate Demonstrations."
Although the print magazine Datamation. itself shuffled off this mortal coil in 1997, I'm proud to say that my 1962 article would stand up pretty well even today. Perhaps even better today. Now that hardly any part of the computer moves, demonstrations are much more challenging to create. Of course, this was supposed to be a humorous article, though not everyone realized it at the time. I received a dozen requests for the Demonstration Compiler—that is, the compiler that compiled fake demonstrations. (Hmm, is there any other kind?)
On page 79 of that issue of Datamation., there's an advertisement from Computer Dynamics of Silver Spring, Maryland. (What ever happened to them.?
"MEMO Re: COMPUTER TIME
Solve your computer problems efficiently and economically by using our 32K, 10 tape IBM 7090 at 450ドル per hour." (That's about 5,000ドル per hour or more in today's dollars.)
Today, 45 years later, I own five computers, each of which is far more powerful than that 7090. As far as their value, I've thrown away a more computing power than that because nobody wanted it. Yes, the ten tape drives would still be a bit expensive today, but why would I want them? I own more than a dozen disk drives, each of which stores far more than those ten tapes.
The list of advertisers from that issue contains many forgotten names of companies selling computers, plus a few companies that are still around but no longer selling computers. Here's some examples:
PHILCO "Philco's on the move."
RCA "What's new at RCA is news in EDP."
GENERAL PRECISION (Surely everyone remembers the RPC-4000.)
ASI "More computation per dollar—on the ASI-210."
GENERAL ELECTRIC "Progress is our most important product."
FRIDEN "This is Practimation."
AUTONETICS "It's called RECOMP III."
TRW "Be operational now with the TRW-130 (AN/UYK-1)"
BENDIX "Is your programming career in a closed loop?"
Bendix didn't actually advertise their machine (no, it wasn't a washing machine), but they were crying out for programmers. And so were most of the others, "from 7,000ドル on up."
Even IBM (who, at last look, was still around), was desperate for programmers to "shape the future of a new technology." Sound familiar? Although machines are millions of times faster and cheaper, some things—human things, mostly—don't seem to change in 45 years:
"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."
Gee, I hope they finish these projects soon. I've been waiting a long time to talk to my computers.
Perhaps, in the end, all this flux of companies and jargon and sales promises is merely an illusion. Perhaps it's what doesn't change that teaches us the most important things about ourselves.
And what is it that doesn't change?
Us.
Oh, the faces change. The names change. But the behavior, the hopes, the visions, the gullibility—they don't change. Maybe that's a prediction you can safely make.
Labels:
consulting,
future,
predicting
Subscribe to:
Posts (Atom)