So, something relatively unique happened last week. As usual, people were talking about testing on the JoelOnSoftware discussion list, and I recommended the context driven school.
One of the posters, Gene Wirchenko, thanked me.
No, that wasn't the unique thing. Sheesh.
What was odd was that he said:
"Matthew, thank you for an excellent link. I particularly liked the link in it to interest analysis."
Interest analysis? Interest Analysis? I had no idea what the guy was talking about.
It turns out that the context-driven definition has been supplemented; there is all kinds of new material. It does into more depth and more explanation. It's even better.
And yes, there is a link to a video about how to conduct a stakeholder interest exercise - you have to scroll down to see it. You might want to check it out again, for the first time.
Monday, April 27, 2009
Friday, April 24, 2009
Integrity - III
As you may have guessed, I've been waxing nostalgic about my time as a military cadet lately. I was a cadet in the Civil Air Patrol for seven years - and, toward the end, also an Army reservist, later national guardsman, later ROTC (college, officers training) cadet.
More than what I did - it seemed at times to be who I was. In other words it was something like software development and testing is to me now.
And yet I have regrets. As my friend Mark tried to point out in order to cheer me up, I staffed encampments, I worked on search and rescue missions (including one distressed find), I served on drill teams, commanded a couple, soloed in a light aircraft before I had a driver's license, and attended national special activities.
And yet I have regrets. I did a fair amount of 'dumb teenager' things. I did a good amount of arguing with my peers and superiors, and more than a few 'principled stands' over issues - some of which mattered, perhaps some did not. Years later, through the haze of old memories and the clarity of life experience, I was regretting some of my actions on a military cadet discussion list. A contemporary officer of mine (my elder, he was an officer when I was a cadet, and a cadet in the 1970's) had something to say that struck me. I think it bears repeating here, and I'd like to thank Elisabeth Hendrickson for encouraging me to blog it:
//first quote
If you can't go all out for a lost cause when you're young, when are you going to do it? When you're young, aren't at war, and nobody's life is on the line, it's not the victory that matters. It's the fight.
We have the rest of our lives to compromise and be reasonable. No one should waste their youth being reasonable.
Matt, I would have preferred one of you for every 10 cadet officers I dealt with at that time who sold out and tried to play political games instead of standing up for what was right. It breaks my heart every time I see some young cadet captain sucking up to me or doing something they know is wrong because they think it will get them something they want (which always turns out to be unimportant to them in the long run).
Our society teaches them that you have to accept bad behavior because the people doing that behavior probably can get you something. Even if they can't, they can probably prevent you from getting it. That's why so many people didn't think it was a big deal that the board and NHQ started ignoring the process for reg changes. That's why congressmen won't take on the big lobbies. That's why the press gave Bush a free pass over the war and other things (until the second term when the problems could no longer be ignored). That's why no one spoke up in the 1980s when the government started to pull apart the regulatory regime installed in the 1930s that had eliminated the "Boom/Bust" cycle that had dominated our economy since this country's inception. That's why most CAP members won't stand up when a commander exceeds their authority...
...and all of that is why this country is in such a mess. Instead of doing the hard thing, everyone wants to take the easy way out, even though, deep down, they know it isn't really the easy way. Every time we compromise principle for a short term goal, every time we look the other way when someone is abusing their authority or breaking the law, every time we take a short cut instead of doing it right, we tear apart the fabric of our society just a little more.
This nation has plenty of weasels. What we need is more people who aren't afraid to stick it out there and risk getting it cut off simply because it's the right thing to do. Thus endeth the sermon. :lol:
//end first quote
//second quote
MHeusser wrote:
>A year later, when I have lunch with one of the old managers, he said
>"yeah, matt, I never had a problem with you, but every once in a while
>I'd hear that you went to a meeting and made someone mad..."
That sums up my entire career at (non profit x) in one sentence. :-)
Anyone who challenges the status quo or refuses to jump on the political bandwagon wins enemies very fast even if they're right, polite, and effective. The political types see you as a threat because you aren't acting in a way they can predict (because they truly don't understand basing decisions on principle instead of expediency). The non-politcal types resent you for demonstrating how gutless they are as they sit there and say nothing in the face of something they know is wrong.
"I mean, who the hell are you to stand up and point out the flaws in the plan? You make us all look bad. [The CEO] doesn't want to hear about that. He just wants to feel things are going smoothly. Stop risking everyones' jobs." (an actual quote from a manager I had to work for when I pointed out that the food distribution points we were using were nowhere near the victims we were supposed to be helping).
Pretty much every great leader was a man or woman who could get away with being principled because their charisma could overcome the bull [poo-poo].
//end second quote
...Times Passes...
A decade after I ended my cadet days, I quit a volunteer role in a software user's group because I was increasingly uncomfortable with the lack of transparency and conflicts of interest in the process. I got an email from a leader in the group, saying that he hoped I got a 'little thrill' from my 'principled stand', that it would hurt my reputation in the community, and he hoped it was worth it, to me.
The leads to Heusser's rule of integrity: When people are deeply upset because you are standing on principle ... you've touched a sore spot, and you could very well be doing exactly the right thing.
Not that I'm perfect, or have attained any kind of perfection - far from it, I have made my share of mistakes. AND, a few years later, I'm still glad I quit that committee.
UPDATE: Let us say, in the example above, that there was no integrity issue with the user's group - it was simply a transparency issue. That the leadership didn't want to be bothered to explain and make the process public because it would be annoying and extra work - not because of any kind of nafarious cover-up. In that case, we're not talking about right or wrong - we are instead talking about "easy" vs "transparent." Which of these is better? This was probably actually the case - should I have still made the fuss?
In that case, we're talking about values and principles - and it is very possible that someone values one thing over another differently than me. That doesn't make them a bad or immoral person. But values directly impact the way we do development - see the The Agile Manifesto for concrete examples of this.
The question is - if someone picks something radically different than you, are you willing to have your name on the Marquee? Are you willing to submit and say "I was only following orders." Some things matter. Some don't. Can we tell the difference?
Standing up for my principles - as a cadet or a programmer - is just that. Standing up for my principles. But I do believe that some principles are better than others; if all principles are same, we end up the children on the island in "Lord of The Flies" pretty quickly, don't we?
What do you think?
More than what I did - it seemed at times to be who I was. In other words it was something like software development and testing is to me now.
And yet I have regrets. As my friend Mark tried to point out in order to cheer me up, I staffed encampments, I worked on search and rescue missions (including one distressed find), I served on drill teams, commanded a couple, soloed in a light aircraft before I had a driver's license, and attended national special activities.
And yet I have regrets. I did a fair amount of 'dumb teenager' things. I did a good amount of arguing with my peers and superiors, and more than a few 'principled stands' over issues - some of which mattered, perhaps some did not. Years later, through the haze of old memories and the clarity of life experience, I was regretting some of my actions on a military cadet discussion list. A contemporary officer of mine (my elder, he was an officer when I was a cadet, and a cadet in the 1970's) had something to say that struck me. I think it bears repeating here, and I'd like to thank Elisabeth Hendrickson for encouraging me to blog it:
//first quote
If you can't go all out for a lost cause when you're young, when are you going to do it? When you're young, aren't at war, and nobody's life is on the line, it's not the victory that matters. It's the fight.
We have the rest of our lives to compromise and be reasonable. No one should waste their youth being reasonable.
Matt, I would have preferred one of you for every 10 cadet officers I dealt with at that time who sold out and tried to play political games instead of standing up for what was right. It breaks my heart every time I see some young cadet captain sucking up to me or doing something they know is wrong because they think it will get them something they want (which always turns out to be unimportant to them in the long run).
Our society teaches them that you have to accept bad behavior because the people doing that behavior probably can get you something. Even if they can't, they can probably prevent you from getting it. That's why so many people didn't think it was a big deal that the board and NHQ started ignoring the process for reg changes. That's why congressmen won't take on the big lobbies. That's why the press gave Bush a free pass over the war and other things (until the second term when the problems could no longer be ignored). That's why no one spoke up in the 1980s when the government started to pull apart the regulatory regime installed in the 1930s that had eliminated the "Boom/Bust" cycle that had dominated our economy since this country's inception. That's why most CAP members won't stand up when a commander exceeds their authority...
...and all of that is why this country is in such a mess. Instead of doing the hard thing, everyone wants to take the easy way out, even though, deep down, they know it isn't really the easy way. Every time we compromise principle for a short term goal, every time we look the other way when someone is abusing their authority or breaking the law, every time we take a short cut instead of doing it right, we tear apart the fabric of our society just a little more.
This nation has plenty of weasels. What we need is more people who aren't afraid to stick it out there and risk getting it cut off simply because it's the right thing to do. Thus endeth the sermon. :lol:
//end first quote
//second quote
MHeusser wrote:
>A year later, when I have lunch with one of the old managers, he said
>"yeah, matt, I never had a problem with you, but every once in a while
>I'd hear that you went to a meeting and made someone mad..."
That sums up my entire career at (non profit x) in one sentence. :-)
Anyone who challenges the status quo or refuses to jump on the political bandwagon wins enemies very fast even if they're right, polite, and effective. The political types see you as a threat because you aren't acting in a way they can predict (because they truly don't understand basing decisions on principle instead of expediency). The non-politcal types resent you for demonstrating how gutless they are as they sit there and say nothing in the face of something they know is wrong.
"I mean, who the hell are you to stand up and point out the flaws in the plan? You make us all look bad. [The CEO] doesn't want to hear about that. He just wants to feel things are going smoothly. Stop risking everyones' jobs." (an actual quote from a manager I had to work for when I pointed out that the food distribution points we were using were nowhere near the victims we were supposed to be helping).
Pretty much every great leader was a man or woman who could get away with being principled because their charisma could overcome the bull [poo-poo].
//end second quote
...Times Passes...
A decade after I ended my cadet days, I quit a volunteer role in a software user's group because I was increasingly uncomfortable with the lack of transparency and conflicts of interest in the process. I got an email from a leader in the group, saying that he hoped I got a 'little thrill' from my 'principled stand', that it would hurt my reputation in the community, and he hoped it was worth it, to me.
The leads to Heusser's rule of integrity: When people are deeply upset because you are standing on principle ... you've touched a sore spot, and you could very well be doing exactly the right thing.
Not that I'm perfect, or have attained any kind of perfection - far from it, I have made my share of mistakes. AND, a few years later, I'm still glad I quit that committee.
UPDATE: Let us say, in the example above, that there was no integrity issue with the user's group - it was simply a transparency issue. That the leadership didn't want to be bothered to explain and make the process public because it would be annoying and extra work - not because of any kind of nafarious cover-up. In that case, we're not talking about right or wrong - we are instead talking about "easy" vs "transparent." Which of these is better? This was probably actually the case - should I have still made the fuss?
In that case, we're talking about values and principles - and it is very possible that someone values one thing over another differently than me. That doesn't make them a bad or immoral person. But values directly impact the way we do development - see the The Agile Manifesto for concrete examples of this.
The question is - if someone picks something radically different than you, are you willing to have your name on the Marquee? Are you willing to submit and say "I was only following orders." Some things matter. Some don't. Can we tell the difference?
Standing up for my principles - as a cadet or a programmer - is just that. Standing up for my principles. But I do believe that some principles are better than others; if all principles are same, we end up the children on the island in "Lord of The Flies" pretty quickly, don't we?
What do you think?
Thursday, April 23, 2009
My SW Craft Blog
I have a software craft blog that I am much less active with than Creative Chaos. I just put a post up on perfectionism and the worse-is-better approach. I think you might enjoy it, and I certainly hope it will surprise you.
Wednesday, April 22, 2009
Integrity - II
Barry Schwartz on Morals and Ethics in the work world:
Replace with "Incentives" with "Metrics" in his speech, and Barry's talk could easily be a keynote level presentation at any software engineering, development, or testing conference.
We would do well to listen ... and respond.
Replace with "Incentives" with "Metrics" in his speech, and Barry's talk could easily be a keynote level presentation at any software engineering, development, or testing conference.
We would do well to listen ... and respond.
Integrity - I
For those who don't know, the US Government is currently offering trillions of dollars - yes, the amount is now in the trillions - to loan or purchase parts of failing banks and other financial institutions. This money is given mostly to cover those banks who would otherwise fail because of so-called "toxic loans."
The CEO of Freddie Mac, one of the agencies given the money, recently resigned. His successor, who was the acting CEO and former Chief Financial Officer, just killed himself. The troubles asset relief program's (TARP) "special investigator" just determined that the entire program is exposed to the potential of massive fraud, waste and abuse. This is very similar to what happened with Enron.
Folks, the Chief Financial Officer is the one responsible for ensuring the proper financial controls are in place. Instead, it's become a powerful position with the opportunity to look the other way or even help cover up fraud and abuse. And some do; the Enron CFO went to jail, and so did the WorldCom CFO.
Now when we discuss this story, it's very easy to get judgemental, and say something like "how do they sleep at night?"
Here's the secret: We are just like them. Integrity challenges are one of gradualism - a little here, (ever make personal photocopies on the work machine?) a little there, and soon it's pattern, a lifestyle, and you are in too deep to get out. Oh, perhaps when we cheated in 9th grade geometry class we got caught, so we didn't try to cheat in college. Perhaps we were never so desperate for work that we were willing to lie (a little bit) on the old resume. We get to big integrity lapses by two things - (1) giving in to small ones, and (2) getting away with it.
The Professor and author C.S. Lewis put it this way in a graduation speech at King's College:
... the prophecy I make is this. To nine out of ten of you the choice which could lead to scoundrelism will come, when it does come, in no very dramatic colors. Obviously bad men, obviously threatening or bribing, will almost certainly not appear. Over a drink or a cup of coffee, disguised as a triviality and sandwiched between two jokes, from the lips of a man, or woman, whom you have recently been getting to know rather better and whom you hope to know better still-just at the moment when you are most anxious not to appear crude, or naif, or a prig-the hint will come. It will be the hint of something which is not quite in accordance with the technical rules of fair play: something which the public, the ignorant, romantic public, would never understand: something which even the outsiders in your own profession are apt to make a fuss about: but something, says your new friend, which "we"-and at the word "we" you try not to blush for mere pleasure-something "we always do." And you will be drawn in, if you are drawn in, not by desire for gain or ease, but simply because at that moment, when the cup was so near your lips, you cannot bear to be thrust back again into the cold outer world. It would be so terrible to see the other man's face-that genial, confidential, delightfully sophisticated face-turn suddenly cold and contemptuous, to know that you had been tried for the Inner Ring and rejected. And then, if you are drawn in, next week it will be something a little further from the rules, and next year something further still, but all in the jolliest, friendliest spirit. It may end in a crash, a scandal, and penal servitude: it may end in millions, a peerage and giving the prizes at your old school. But you will be a scoundrel.
If you've been working in technology long enough, you've probably felt this. Yes, perhaps over coffee, right after mentioning that your annual review is coming up and right before talking about your potential to be a senior, or lead, or manager, the elder who is mentoring you says that "of course, it would be unprofessional to talk about problems with the software at the meeting with the customer", or perhaps "I just need you to sign off on XYZ testing" when you both know that XYZ testing hasn't been performed - and it might not even work.
Integrity challenges are like that - they come under pressure, when you didn't have enough sleep, they offer great reward if you could just shut up about it, punishment if you can't, and give you five to seven seconds to respond.
If it were easy, it wouldn't challenge your integrity.
More to come.
The CEO of Freddie Mac, one of the agencies given the money, recently resigned. His successor, who was the acting CEO and former Chief Financial Officer, just killed himself. The troubles asset relief program's (TARP) "special investigator" just determined that the entire program is exposed to the potential of massive fraud, waste and abuse. This is very similar to what happened with Enron.
Folks, the Chief Financial Officer is the one responsible for ensuring the proper financial controls are in place. Instead, it's become a powerful position with the opportunity to look the other way or even help cover up fraud and abuse. And some do; the Enron CFO went to jail, and so did the WorldCom CFO.
Now when we discuss this story, it's very easy to get judgemental, and say something like "how do they sleep at night?"
Here's the secret: We are just like them. Integrity challenges are one of gradualism - a little here, (ever make personal photocopies on the work machine?) a little there, and soon it's pattern, a lifestyle, and you are in too deep to get out. Oh, perhaps when we cheated in 9th grade geometry class we got caught, so we didn't try to cheat in college. Perhaps we were never so desperate for work that we were willing to lie (a little bit) on the old resume. We get to big integrity lapses by two things - (1) giving in to small ones, and (2) getting away with it.
The Professor and author C.S. Lewis put it this way in a graduation speech at King's College:
... the prophecy I make is this. To nine out of ten of you the choice which could lead to scoundrelism will come, when it does come, in no very dramatic colors. Obviously bad men, obviously threatening or bribing, will almost certainly not appear. Over a drink or a cup of coffee, disguised as a triviality and sandwiched between two jokes, from the lips of a man, or woman, whom you have recently been getting to know rather better and whom you hope to know better still-just at the moment when you are most anxious not to appear crude, or naif, or a prig-the hint will come. It will be the hint of something which is not quite in accordance with the technical rules of fair play: something which the public, the ignorant, romantic public, would never understand: something which even the outsiders in your own profession are apt to make a fuss about: but something, says your new friend, which "we"-and at the word "we" you try not to blush for mere pleasure-something "we always do." And you will be drawn in, if you are drawn in, not by desire for gain or ease, but simply because at that moment, when the cup was so near your lips, you cannot bear to be thrust back again into the cold outer world. It would be so terrible to see the other man's face-that genial, confidential, delightfully sophisticated face-turn suddenly cold and contemptuous, to know that you had been tried for the Inner Ring and rejected. And then, if you are drawn in, next week it will be something a little further from the rules, and next year something further still, but all in the jolliest, friendliest spirit. It may end in a crash, a scandal, and penal servitude: it may end in millions, a peerage and giving the prizes at your old school. But you will be a scoundrel.
If you've been working in technology long enough, you've probably felt this. Yes, perhaps over coffee, right after mentioning that your annual review is coming up and right before talking about your potential to be a senior, or lead, or manager, the elder who is mentoring you says that "of course, it would be unprofessional to talk about problems with the software at the meeting with the customer", or perhaps "I just need you to sign off on XYZ testing" when you both know that XYZ testing hasn't been performed - and it might not even work.
Integrity challenges are like that - they come under pressure, when you didn't have enough sleep, they offer great reward if you could just shut up about it, punishment if you can't, and give you five to seven seconds to respond.
If it were easy, it wouldn't challenge your integrity.
More to come.
Tuesday, April 21, 2009
If I user twitter, does that make me a twit?
Twitter is interesting because you can say something and others can respond; when you search for a username you get the entire conversation around that individual. This means you see a discussion and back and forth, not just some pontification.
We've had some particularly interesting conversations on twitter lately; if you search for mheusser, you can catch some. Generally, read from the bottom-up. I hope you enjoy it.
We've had some particularly interesting conversations on twitter lately; if you search for mheusser, you can catch some. Generally, read from the bottom-up. I hope you enjoy it.
Thursday, April 16, 2009
Where's Waldo?
Fifteen years ago I was a cadet in the Civil Air Patrol - this picture was taken at the Middle East Region Cadet Competition in 1995 (click for full-size):
This one was taken about two years ago, in my back yard:
Go back to picture #1. Can you find Waldo? Er, umh, Heusser-o?
Can you believe I've had the same haircut for fifteen years?
Serious this time: The modern age is tearing apart families and relationships. During the great depression, when you lost your house, you'd move across town and move back in with Mom&Dad, or Sis, or Old Aunt Ruth. The Modern Era tore apart all that - we've moved for jobs, moved for college, moved to the place of the country (or planet) we like the most, moved and moved and moved and moved. Relationships broke down; five years after high school, I had contact with zero - ZERO - people I went to high school with, and family was sporadic and occasional calls and emails. Now you can't move in with Aunt Ruth because she is a stranger that lives 2,000 miles away. You're stuck with no job and a mortgage you can't afford.
Yet we suddenly have email, yahoo groups, facebook and myspace. I'm more in touch now with some high school folks than was when I was in high school.
Not to be a pessimist, but I am convinced the economic tide is going to get worse - for an extended period of time - before it gets better. Basically, individuals have to unroll themselves from debt, which means less spending, which means banks will fail, which means government spending, which means inflation ... it's going to be bad.
What I'm wondering is - can we use these new social media tools - facebook, (cough) myspace, twitter, instant messanger and so on - to pull together in the way that families did in the 1930's? And what would that look like, exactly?
In the mean time, I made a post to the forums on Spaatz.org, which got me in touch with Alisha 'Copesetic' Christian(*), which ended up with pictures from ... 1995.
regards,
--heusser
(*) -it was a funnier joke when her last name was Cope, I know.
This one was taken about two years ago, in my back yard:
Go back to picture #1. Can you find Waldo? Er, umh, Heusser-o?
Can you believe I've had the same haircut for fifteen years?
Serious this time: The modern age is tearing apart families and relationships. During the great depression, when you lost your house, you'd move across town and move back in with Mom&Dad, or Sis, or Old Aunt Ruth. The Modern Era tore apart all that - we've moved for jobs, moved for college, moved to the place of the country (or planet) we like the most, moved and moved and moved and moved. Relationships broke down; five years after high school, I had contact with zero - ZERO - people I went to high school with, and family was sporadic and occasional calls and emails. Now you can't move in with Aunt Ruth because she is a stranger that lives 2,000 miles away. You're stuck with no job and a mortgage you can't afford.
Yet we suddenly have email, yahoo groups, facebook and myspace. I'm more in touch now with some high school folks than was when I was in high school.
Not to be a pessimist, but I am convinced the economic tide is going to get worse - for an extended period of time - before it gets better. Basically, individuals have to unroll themselves from debt, which means less spending, which means banks will fail, which means government spending, which means inflation ... it's going to be bad.
What I'm wondering is - can we use these new social media tools - facebook, (cough) myspace, twitter, instant messanger and so on - to pull together in the way that families did in the 1930's? And what would that look like, exactly?
In the mean time, I made a post to the forums on Spaatz.org, which got me in touch with Alisha 'Copesetic' Christian(*), which ended up with pictures from ... 1995.
regards,
--heusser
(*) -it was a funnier joke when her last name was Cope, I know.
Tuesday, April 14, 2009
What do you believe about information systems?
This I am currently teaching a second-semester-freshman course on Computing with Spreadsheets. The book focuses on click-here, click-there, clicky-clicky-everywhere with formulas, functions, and graphs, but I'm trying to make the lectures go a bit beyond that - to explore questions like why the students are in the class, and what are we trying to do?
I'm thinking of creating a sort of business or note card, via something like vistaprint, to hand out at the end of class. The idea is to put it in your wallet, maybe tac it up on your cube some day (I have a few graduating seniors who are catching up on core graduation requirements) - to be reminded of some of the core tenants of IS.
The College is a Calvin College, a four-year Christian liberal arts institution based on the Christian Reformed Tradition.
So far, this is the idea I have; what do you think?
Tenets and Thoughts on Information Systems (front side of card)
Data is not information. Information is not Knowledge. Knowledge is not Wisdom. Wisdom is not Truth.
In the absence of a story but the presence of data, people may invent a story to match the data. This is dangerous.
Because of this we can not 'let the data speak for itself'; we can, however, strive to tell a compelling story, with integrity, that stands up to scrutiny.
There are some things that can not be quantified, so it is inadvisable to make decisions based on measurable numbers alone. We call this distinction qualitative vs. quantitative metrics. (Example: If you cannot control what you cannot measure - how do you decide that you need a hair cut? Do you get out a ruler to measure your hair?)
Our measurement tools can be wonderful aids, but from this we should not forget: A fool with a tool is still a fool.
(Back Side of Card)
Clerks follow a stable, predictable, defined process. Heroes, on the other hand, take a vague and ambiguous problem, under time and resource constraints and in the face of conflicting requirements - and solve it. Managers provide vision and ensure that heroes are not taxed beyond their breaking point. Our society needs them all. Who do you want to be?
The tendency to take people and view them as numbers in a spreadsheet can be very strong; but that does not make it right.
The word 'Truth' appears 228 times in the the Bible, 'Respect' appears 44. - 'For what is a man profited, if he shall gain the whole world, and lose his own soul?' (Matthew 16:26, KJV)
Do you think I'm missing something important? Would a different order be helpful? Does the wording stink? Should I work harder to credit Frank Zappa or the Context Driven School of testing for the initial statements, or W. Edwards Deming for the idea that not everything can be measured? Do you think i'm fundamentally off base?
You may not like this list - I'm not super hot on it either. It turns out, condensing my philosophy of IS into a hundred words is not an easy thing. I'd like to make it better, which means I would really appreciate hearing from you.
I'm thinking of creating a sort of business or note card, via something like vistaprint, to hand out at the end of class. The idea is to put it in your wallet, maybe tac it up on your cube some day (I have a few graduating seniors who are catching up on core graduation requirements) - to be reminded of some of the core tenants of IS.
The College is a Calvin College, a four-year Christian liberal arts institution based on the Christian Reformed Tradition.
So far, this is the idea I have; what do you think?
Tenets and Thoughts on Information Systems (front side of card)
Data is not information. Information is not Knowledge. Knowledge is not Wisdom. Wisdom is not Truth.
In the absence of a story but the presence of data, people may invent a story to match the data. This is dangerous.
Because of this we can not 'let the data speak for itself'; we can, however, strive to tell a compelling story, with integrity, that stands up to scrutiny.
There are some things that can not be quantified, so it is inadvisable to make decisions based on measurable numbers alone. We call this distinction qualitative vs. quantitative metrics. (Example: If you cannot control what you cannot measure - how do you decide that you need a hair cut? Do you get out a ruler to measure your hair?)
Our measurement tools can be wonderful aids, but from this we should not forget: A fool with a tool is still a fool.
(Back Side of Card)
Clerks follow a stable, predictable, defined process. Heroes, on the other hand, take a vague and ambiguous problem, under time and resource constraints and in the face of conflicting requirements - and solve it. Managers provide vision and ensure that heroes are not taxed beyond their breaking point. Our society needs them all. Who do you want to be?
The tendency to take people and view them as numbers in a spreadsheet can be very strong; but that does not make it right.
The word 'Truth' appears 228 times in the the Bible, 'Respect' appears 44. - 'For what is a man profited, if he shall gain the whole world, and lose his own soul?' (Matthew 16:26, KJV)
Do you think I'm missing something important? Would a different order be helpful? Does the wording stink? Should I work harder to credit Frank Zappa or the Context Driven School of testing for the initial statements, or W. Edwards Deming for the idea that not everything can be measured? Do you think i'm fundamentally off base?
You may not like this list - I'm not super hot on it either. It turns out, condensing my philosophy of IS into a hundred words is not an easy thing. I'd like to make it better, which means I would really appreciate hearing from you.
Monday, April 13, 2009
... and the lighter side
- From xkcd.com
... And SwashBooking
No, I spelled it right - Swash-Booking. My collegue and friend James Bach, has a new video up on Competitive Swashbooking. The basic idea is that you take eight hours and skim from a library of 110 books, then present on what you found most interesting. Watch the video and the crique James's son does at the end -- tell me that's not critical investigation worthy of a skilled tester.
Finally, I've got several more alternatives to certification, coming up next.
Stay tuned!
Friday, April 10, 2009
Alternatives to (testing) Certification
Earlier in the week, I suggested that certification was one way to demonstrate commitment to craft - that there were other ways. Lisa Crispin asked me to expand on what people could do if they don't want to do the writing/speaking thing.
That's fair enough. Some people don't have the ego or desire to be in the front of the room. Certainly certification is a valid alternative, right?
Well, maybe. As a merit badge. But this got me to thinking - Here are a few other things you can do to demonstrate commitment to the field:
- I'm certainly pro-education; I'm just ambivalent about the title "certified" tester. I'm not excited about what it implies - and if it can keep it's promises. the Association For Software Testing offers free training to members. That training offers real exercises and real class interaction, done online, over a period of weeks, that takes significant work outside of class. I'm suggesting that you don't just take a single test - take a dozen of them. Membership is in the area of $85 US Dollars per year; AST is one of two organizations for which I pay my own membership out of pocket.
- I'm certainly pro-education! I'm suggesting more than just a test or two - go back to school at night and earn that Bachelor's degree, or even that Master's, in Software Engineering, Computer Science, or IT Management. A master's degree should take at least a thousand hours of your effort. Compare that to a typical software testing certificate. Try not to weep. (I earned my MS in Computer Information Systems from Grand Valley by going back to school at night from 2000-2004. It was hard. It was an investment.)
- Volunteer at a local user's group. This doesn't have to be as president or big person at the head table. You can do program chair duties, where you'll get a chance to meet and connect with the people who are speaking - and every user's group had work like secretary that just needs to be done, which will help you meet the board. And if you want to learn website maintenance, I bet they need a web-master. Don't have a local user's group? You can found one - I started the Grand Rapids Perl user's group in 1998, and the second Grand Rapid's testing lunch is April 27th.
- Volunteer at a regional software or testing conference. Don't have one? You can start one - I've been involved in Grand Rapids Bar Camp, and served as the lead organizer of the Great Lakes Software Excellence Conference (www.glsec.org) in 2006. The Conference continues to this day.
- Join a discussion list like SW-IMPROVE, Agile-Testing, or Software-Testing. You don't have to be a big "speaker man" to answer a question when someone had a problem. And, sooner or later, you may get some reputation as "helpful." That's a good reputation to have.
- Attend Peer workshops like the Indianapolis Workshop On Software Testing or the Los Altos Workshops on Software Testing. These workshops are usually free, and if you look hard enough, you may be able to find grants to cover your travel. If a workshop is too hard away, start one locally - I ran the Workshop on Technical Debt in Grand Rapids in 2008.
- Get involved on the forums on SoftwareTestingClub or another, closer testing site. (SoftwareTestingClub is mostly UK-based). You don't have to be a guru to be helpful - and you can learn a lot from peers. You might also consider getting a twitter account or starting your own blog. A blog can be, in many ways, a sort of public journal. Be careful about airing dirty laundry, but, otherwise, it can be a great place to explore ideas and get feedback.
- For that matter, if you're not comfortable blogging, you could simply leave comments on good sites that match your interest - perhaps attending some public conferences and meeting some of the people you've commented with.
I hope, at this point, you'll agree that certification is one way to demonstrate interest in your profession - one way out of dozens. If you want to demonstrate learning and improvement outside your profession, there are lots of more traditional ways; you can join toastmasters, or the Rotarians, or coach a sport, or teach Sunday School.
If you have more ideas of other professional develop ideas, please feel free to leave comments.
"Choose Wisely"
UPDATE: Yesterday I had a great conversation with Gary Mogyorodi, president of the Canadian Software Testing Board. He genuinely impressed me as a smart person with integrity trying to do the right things - to reform the system from within.
Now, it's hard to tell these things for certain over a thirty-minute phone call, but Gary points out that studying for the foundation level on your own time is considered standard, if not encouraged, in Canada, and that the test to focus on is the Advanced level, which is a more context-driven, essay-format test. I still have concerns about ISTQB, but it was a refeshingly honest conversation. As I rule, I don't endorse any test certification scheme - but I might recommend Gary Mogyorodi, and I hope to get to work with him and know him better in the future.
That's fair enough. Some people don't have the ego or desire to be in the front of the room. Certainly certification is a valid alternative, right?
Well, maybe. As a merit badge. But this got me to thinking - Here are a few other things you can do to demonstrate commitment to the field:
- I'm certainly pro-education; I'm just ambivalent about the title "certified" tester. I'm not excited about what it implies - and if it can keep it's promises. the Association For Software Testing offers free training to members. That training offers real exercises and real class interaction, done online, over a period of weeks, that takes significant work outside of class. I'm suggesting that you don't just take a single test - take a dozen of them. Membership is in the area of $85 US Dollars per year; AST is one of two organizations for which I pay my own membership out of pocket.
- I'm certainly pro-education! I'm suggesting more than just a test or two - go back to school at night and earn that Bachelor's degree, or even that Master's, in Software Engineering, Computer Science, or IT Management. A master's degree should take at least a thousand hours of your effort. Compare that to a typical software testing certificate. Try not to weep. (I earned my MS in Computer Information Systems from Grand Valley by going back to school at night from 2000-2004. It was hard. It was an investment.)
- Volunteer at a local user's group. This doesn't have to be as president or big person at the head table. You can do program chair duties, where you'll get a chance to meet and connect with the people who are speaking - and every user's group had work like secretary that just needs to be done, which will help you meet the board. And if you want to learn website maintenance, I bet they need a web-master. Don't have a local user's group? You can found one - I started the Grand Rapids Perl user's group in 1998, and the second Grand Rapid's testing lunch is April 27th.
- Volunteer at a regional software or testing conference. Don't have one? You can start one - I've been involved in Grand Rapids Bar Camp, and served as the lead organizer of the Great Lakes Software Excellence Conference (www.glsec.org) in 2006. The Conference continues to this day.
- Join a discussion list like SW-IMPROVE, Agile-Testing, or Software-Testing. You don't have to be a big "speaker man" to answer a question when someone had a problem. And, sooner or later, you may get some reputation as "helpful." That's a good reputation to have.
- Attend Peer workshops like the Indianapolis Workshop On Software Testing or the Los Altos Workshops on Software Testing. These workshops are usually free, and if you look hard enough, you may be able to find grants to cover your travel. If a workshop is too hard away, start one locally - I ran the Workshop on Technical Debt in Grand Rapids in 2008.
- Get involved on the forums on SoftwareTestingClub or another, closer testing site. (SoftwareTestingClub is mostly UK-based). You don't have to be a guru to be helpful - and you can learn a lot from peers. You might also consider getting a twitter account or starting your own blog. A blog can be, in many ways, a sort of public journal. Be careful about airing dirty laundry, but, otherwise, it can be a great place to explore ideas and get feedback.
- For that matter, if you're not comfortable blogging, you could simply leave comments on good sites that match your interest - perhaps attending some public conferences and meeting some of the people you've commented with.
I hope, at this point, you'll agree that certification is one way to demonstrate interest in your profession - one way out of dozens. If you want to demonstrate learning and improvement outside your profession, there are lots of more traditional ways; you can join toastmasters, or the Rotarians, or coach a sport, or teach Sunday School.
If you have more ideas of other professional develop ideas, please feel free to leave comments.
"Choose Wisely"
UPDATE: Yesterday I had a great conversation with Gary Mogyorodi, president of the Canadian Software Testing Board. He genuinely impressed me as a smart person with integrity trying to do the right things - to reform the system from within.
Now, it's hard to tell these things for certain over a thirty-minute phone call, but Gary points out that studying for the foundation level on your own time is considered standard, if not encouraged, in Canada, and that the test to focus on is the Advanced level, which is a more context-driven, essay-format test. I still have concerns about ISTQB, but it was a refeshingly honest conversation. As I rule, I don't endorse any test certification scheme - but I might recommend Gary Mogyorodi, and I hope to get to work with him and know him better in the future.
Thursday, April 09, 2009
Can we talk testing without testing philosophy?
My latest post to the agile-testing yahoo group:
Ben Simo asks how we can talk testing without talking philosophy.
If you will permit me, I will try to expand on that. As I see it, software testing is questioning the product, asking questions like "Is this Good (Enough)?"
To do that, you need to answer questions like "What does 'Good Software' mean?" "What does 'Good' mean?" and pretty soon you are asking "What does 'meaning' mean?"
The good news is that we can stop wayyyy short of that final question and still declare victory.
So we define good according to a value system - for example - we value this over that, because we value this outcome over that outcome -- applied philosophy. I am not the first person to notice this[1, 2].
So that is what geeks me out about testing. I suspect, that by philosophy, Lisa means to stay away from the arguments about "is testing critical inquiry?" or "is testing a repeatable process that should be automated all the time?"
This is very hard for some of us to do, as ideas have consequences, and our worldview will impact our work.
/AND/ here is what I can try (harder) to do in good conscience: When things get airy fairy, we can bring them down to THIS report, THIS web screen, or THIS server product, and it's constraints, and what test strategy we would develop.
I believe that's what we are being asked to do. I'm not excited about it, but I understand the concern and I'll try to keep things grounded in good faith.
Fair 'Nuff?
Regards,
--heusser
[1] http://www.satisfice.com/aboutjames.shtml
[2] http://www.paulgraham.com/philosophy.html
Ben Simo asks how we can talk testing without talking philosophy.
If you will permit me, I will try to expand on that. As I see it, software testing is questioning the product, asking questions like "Is this Good (Enough)?"
To do that, you need to answer questions like "What does 'Good Software' mean?" "What does 'Good' mean?" and pretty soon you are asking "What does 'meaning' mean?"
The good news is that we can stop wayyyy short of that final question and still declare victory.
So we define good according to a value system - for example - we value this over that, because we value this outcome over that outcome -- applied philosophy. I am not the first person to notice this[1, 2].
So that is what geeks me out about testing. I suspect, that by philosophy, Lisa means to stay away from the arguments about "is testing critical inquiry?" or "is testing a repeatable process that should be automated all the time?"
This is very hard for some of us to do, as ideas have consequences, and our worldview will impact our work.
/AND/ here is what I can try (harder) to do in good conscience: When things get airy fairy, we can bring them down to THIS report, THIS web screen, or THIS server product, and it's constraints, and what test strategy we would develop.
I believe that's what we are being asked to do. I'm not excited about it, but I understand the concern and I'll try to keep things grounded in good faith.
Fair 'Nuff?
Regards,
--heusser
[1] http://www.satisfice.com/aboutjames.shtml
[2] http://www.paulgraham.com/philosophy.html
April STP Magazine - And an article
For the April Issue of Software Test and Performance Magazine, Chris McMahon and I interview Paul Melson about security and penetration testing; the interview appears on page 9.
Of course, PDFS of STPMag are always free to download, and you can always apply for a free print subscription to the magazine.
Of course, PDFS of STPMag are always free to download, and you can always apply for a free print subscription to the magazine.
Wednesday, April 08, 2009
Plagarism?
I got an email today with a link to this post, pointing out that the vast majority of the material was simply taken from my site without attribution. In "the west" (the united states and Europe) we consider this plagarism; in college, it can get you kicked out - in publishing, it can land you in jail.
I choose to be flattered. But, if the author wanted to add an attribution and link to Creative Chaos - gosh, that would actually be nice.
UPDATE: The author apologized and removed his material from his blog, implying it was a coincidence. I wish we could have talked; if it was a coincidence, he didn't need to remove it. If it wasn't, I'd just like a little credit! :-)
I choose to be flattered. But, if the author wanted to add an attribution and link to Creative Chaos - gosh, that would actually be nice.
UPDATE: The author apologized and removed his material from his blog, implying it was a coincidence. I wish we could have talked; if it was a coincidence, he didn't need to remove it. If it wasn't, I'd just like a little credit! :-)
Tuesday, April 07, 2009
Quality, Agility, Maturity, and Discipline
A few weeks back, James Bach made a post on the death of quality. In the comments, Michael Butler wrote:
I think we should toss the word ‘quality’, period. Instead, ask people to describe what qualities they believe make good software
To expand on that with my words - we use 'Quality' as a sort of shorthand. Instead of saying exactly what we mean - which might be "fast", or "pretty", or "free from defects", or even "good value for the money", we sum up that idea in 'Quality' - a single, short, easy-to-transmit symbol.
The person who hears us then interprets that in his or her own way. And it's very easy to do. So you get into these arguments about whether or not, say, Microsoft Vista is a good quality product, and you realize people aren't arguing about how Vista performs, or it's features, but are instead arguing about the definition of Quality.
Do you think that's an argument that's ever going to actually "wind down" and come to consensus? Somehow, I doubt it.
It turns out we do this all the time in software development.
In fact, it's a very subtle subconscious ploy. Let's say you don't like something new - say, the Agile Manifesto in 2002. How do you make it clear that whatever you are doing is better than 'Agile'?
Well, you could come up with a specific, concrete examples and metrics - or you could try logic - or anecdote. But those take a lot of work and investment on the time of your readers.
You could just say that Agile Development is "Immature." Or perhaps "Undisciplined." Think that accusation never happens? Did you know that Barry Boehm published a book in 2003 called Balancing Agility and Discipline
?
Yet I would hold that for any conventional definition of discipline, to do tests /before/ you write code, to mercilessly refactor, and to write acceptance tests before you start writing code - even in the face of apparent schedule pressure, actually requires a great deal of discipline.
Likewise, Maturity is another word you can throw around. It's easy enough to define a five-level (Or three level, as the case may be) maturity scale and place yourself at the top.
In these cases, "Quality", "Agility", "Maturity" and "Discpline" are all, well, code words: They mean "Good."
Using these terms allows the speaker to assert "my process/product/company is gooder than yours" and appear somewhat objective.
The problem is, if you're going to use one of these terms, you have to define what the word means for you.
Take, for example, Maturity. The simple definition of this word is "Grown Up." The more complex, common-usage definition is that the person has his or her own studied and well-considered value system - that they know what they stand for, why they stand for it, and they are willing to live with the consequences.
Thus, we call the 18-year-old who chains himself to a tree to prevent deforestation, and whines and complains and cries when he his thrown in jail immature, but the 40-year-old who expected it and takes it stoically as mature - and through age usually brings maturity, we would do so even if the ages were reversed.
So Maturity means knowing what /you/ stand for. Therefore, a maturity model needs to stand for something, to value certain things over others, because methodology design involves tradeoffs.
So companies that climb a maturity model are, in fact, saying "Look at us; we're mature, we are doing what someone else told us was good!"
I don't buy it.
But there's something else going on with maturity models - what is that value system? Is it explicit? What ideal are they striving toward? When I look at the 200-odd page CMMI document, I don't see the word Maturity defined. That concerns me.
To some extent, I argue that software development has physics envy - we want so badly to have formulas, models and numbers, that we look up to the first naive attempts at metrics and maturity without examining the system effects.
Some models are valid; the periodic table of the elements, for example, doesn't just list the elements that were known at the time - it's format and shape conforms to the nature of the universe. We could use the periodic table to know what elements we had not found yet (they were on the chart but missing) and even to predict the atomic weight of those objects.
Are our definitions of Quality, Agility, Maturity, and Discipline good enough that we can predict real improvement? Or are they just shorthand for "good according to my value system."?
I submit that when it's the latter, we are obligated to list our value system, explain why, and perhaps drop loaded words like "Maturity" and "Discipline" from our vocabulary. I've certainly tried that and I continue to try and learn by way of this blog.
I've been studying software development with a passion for my entire adult life, often publicly. You may not agree with me - but I hope you agree my approach is somewhat rigorous, studied, reasoned, I know what I stand for and am willing to live with the consequences.
That's the best I've got. I welcome your comments.
I think we should toss the word ‘quality’, period. Instead, ask people to describe what qualities they believe make good software
To expand on that with my words - we use 'Quality' as a sort of shorthand. Instead of saying exactly what we mean - which might be "fast", or "pretty", or "free from defects", or even "good value for the money", we sum up that idea in 'Quality' - a single, short, easy-to-transmit symbol.
The person who hears us then interprets that in his or her own way. And it's very easy to do. So you get into these arguments about whether or not, say, Microsoft Vista is a good quality product, and you realize people aren't arguing about how Vista performs, or it's features, but are instead arguing about the definition of Quality.
Do you think that's an argument that's ever going to actually "wind down" and come to consensus? Somehow, I doubt it.
It turns out we do this all the time in software development.
In fact, it's a very subtle subconscious ploy. Let's say you don't like something new - say, the Agile Manifesto in 2002. How do you make it clear that whatever you are doing is better than 'Agile'?
Well, you could come up with a specific, concrete examples and metrics - or you could try logic - or anecdote. But those take a lot of work and investment on the time of your readers.
You could just say that Agile Development is "Immature." Or perhaps "Undisciplined." Think that accusation never happens? Did you know that Barry Boehm published a book in 2003 called Balancing Agility and Discipline
?Yet I would hold that for any conventional definition of discipline, to do tests /before/ you write code, to mercilessly refactor, and to write acceptance tests before you start writing code - even in the face of apparent schedule pressure, actually requires a great deal of discipline.
Likewise, Maturity is another word you can throw around. It's easy enough to define a five-level (Or three level, as the case may be) maturity scale and place yourself at the top.
In these cases, "Quality", "Agility", "Maturity" and "Discpline" are all, well, code words: They mean "Good."
Using these terms allows the speaker to assert "my process/product/company is gooder than yours" and appear somewhat objective.
The problem is, if you're going to use one of these terms, you have to define what the word means for you.
Take, for example, Maturity. The simple definition of this word is "Grown Up." The more complex, common-usage definition is that the person has his or her own studied and well-considered value system - that they know what they stand for, why they stand for it, and they are willing to live with the consequences.
Thus, we call the 18-year-old who chains himself to a tree to prevent deforestation, and whines and complains and cries when he his thrown in jail immature, but the 40-year-old who expected it and takes it stoically as mature - and through age usually brings maturity, we would do so even if the ages were reversed.
So Maturity means knowing what /you/ stand for. Therefore, a maturity model needs to stand for something, to value certain things over others, because methodology design involves tradeoffs.
So companies that climb a maturity model are, in fact, saying "Look at us; we're mature, we are doing what someone else told us was good!"
I don't buy it.
But there's something else going on with maturity models - what is that value system? Is it explicit? What ideal are they striving toward? When I look at the 200-odd page CMMI document, I don't see the word Maturity defined. That concerns me.
To some extent, I argue that software development has physics envy - we want so badly to have formulas, models and numbers, that we look up to the first naive attempts at metrics and maturity without examining the system effects.
Some models are valid; the periodic table of the elements, for example, doesn't just list the elements that were known at the time - it's format and shape conforms to the nature of the universe. We could use the periodic table to know what elements we had not found yet (they were on the chart but missing) and even to predict the atomic weight of those objects.
Are our definitions of Quality, Agility, Maturity, and Discipline good enough that we can predict real improvement? Or are they just shorthand for "good according to my value system."?
I submit that when it's the latter, we are obligated to list our value system, explain why, and perhaps drop loaded words like "Maturity" and "Discipline" from our vocabulary. I've certainly tried that and I continue to try and learn by way of this blog.
I've been studying software development with a passion for my entire adult life, often publicly. You may not agree with me - but I hope you agree my approach is somewhat rigorous, studied, reasoned, I know what I stand for and am willing to live with the consequences.
That's the best I've got. I welcome your comments.
Monday, April 06, 2009
Learning from Management
Business Management is a new field that evolved in the 20th century - that, for the most part, has a jump on software development by about fifty years.
This weekend, I borrowed my late father-in-law's very old, very dog-eared copy of Harvard Business Review on Management
. The book is a collection of essays on business management; I'd like to reproduce part of the first page of the first essay here:
The upper reaches of management are a land of mystery and intrigue. Very few people have been there, and the present inhabitants frequently send messages that are incoherent both to other layers of management and to the world in general. This may account for the myths, illusions, and caricatures that permeate the literature of management- for example, such widely held notions are these:
- Life gets less complicated as a manager reaches the top of the pyramid.
- The manager at the top level knows everything that's going on in the organization, can command whatever resources he may need, and therefore can be more decisive.
- The general manager's day is taken up with making broad policy decisions and formulating precise objectives.
- The top executive's primary activity is conceptualizing long-range plans.
- In a large company, the top executive can be seen meditating about the role of his organization in society.
I suggest that none of these versions alone, or in combination, is an accurate portrayal of what a general manager does. Perhaps students of the management process have been overly eager to developer a theory and a discipline. As one executive I know puts it "I guess I do some of the things described in the books and articles, but the descriptions are lifeless, and my job isn't"
Does any of that sound familiar?
An industry over-eager to develop a theory and "professional discipline" around it's work. Books that talk about a form of the profession yet lack the substance. "Experts", mythology, and a second look at what it means to be a leader.
That second look, by the way, took a long time in coming. My father-in-laws edition of On Management was initially published in 1975, but that article was originally published in 1967. (HBR re-published it in 1984, and the 1984 edition is available on-line for free. Thanks, Harvard!)
In fact, one could argue that corporate America today is still in the grip of Command and Control management that this author was arguing against.
However, I can add that he had influence. A number of companies, even in manufacturing, are embracing lean and empowing the workforce in a meaningful, non-buzzword way. Slowly those companies are becoming more competitive and beating their competition.
Today, arguably, software testing is about where business management was in 1967. We have a few voices crying out in the wilderness, a good bit of myth and legend, gurus and opinions.
That means we have plenty of work to do.
Fifty years ago, Edward Wrapp wrote a essay that took him to the top of his field -- and is still read today. Our field is wide open; you could very well be the next Edward Wrapp.
Let's seize the day.
UPDATE: Someone is going to read this and say "but I've never heard of Alfred Wrapp." Well, ok. So he didn't give the big speeches and collect the alcollades and honors and sit at the head table. His work was instrumental in changing the perception of American Business. He was what C.S. Lewis refers to as The Sound Craftsman. That's good enough for me.
Still to come: Meaningful alternatives to certification for people who don't want to write or speak, and also, my take on the terms "Maturity" and "Discipline" in software development. Don't miss it!
This weekend, I borrowed my late father-in-law's very old, very dog-eared copy of Harvard Business Review on Management
. The book is a collection of essays on business management; I'd like to reproduce part of the first page of the first essay here:The upper reaches of management are a land of mystery and intrigue. Very few people have been there, and the present inhabitants frequently send messages that are incoherent both to other layers of management and to the world in general. This may account for the myths, illusions, and caricatures that permeate the literature of management- for example, such widely held notions are these:
- Life gets less complicated as a manager reaches the top of the pyramid.
- The manager at the top level knows everything that's going on in the organization, can command whatever resources he may need, and therefore can be more decisive.
- The general manager's day is taken up with making broad policy decisions and formulating precise objectives.
- The top executive's primary activity is conceptualizing long-range plans.
- In a large company, the top executive can be seen meditating about the role of his organization in society.
I suggest that none of these versions alone, or in combination, is an accurate portrayal of what a general manager does. Perhaps students of the management process have been overly eager to developer a theory and a discipline. As one executive I know puts it "I guess I do some of the things described in the books and articles, but the descriptions are lifeless, and my job isn't"
Does any of that sound familiar?
An industry over-eager to develop a theory and "professional discipline" around it's work. Books that talk about a form of the profession yet lack the substance. "Experts", mythology, and a second look at what it means to be a leader.
That second look, by the way, took a long time in coming. My father-in-laws edition of On Management was initially published in 1975, but that article was originally published in 1967. (HBR re-published it in 1984, and the 1984 edition is available on-line for free. Thanks, Harvard!)
In fact, one could argue that corporate America today is still in the grip of Command and Control management that this author was arguing against.
However, I can add that he had influence. A number of companies, even in manufacturing, are embracing lean and empowing the workforce in a meaningful, non-buzzword way. Slowly those companies are becoming more competitive and beating their competition.
Today, arguably, software testing is about where business management was in 1967. We have a few voices crying out in the wilderness, a good bit of myth and legend, gurus and opinions.
That means we have plenty of work to do.
Fifty years ago, Edward Wrapp wrote a essay that took him to the top of his field -- and is still read today. Our field is wide open; you could very well be the next Edward Wrapp.
Let's seize the day.
UPDATE: Someone is going to read this and say "but I've never heard of Alfred Wrapp." Well, ok. So he didn't give the big speeches and collect the alcollades and honors and sit at the head table. His work was instrumental in changing the perception of American Business. He was what C.S. Lewis refers to as The Sound Craftsman. That's good enough for me.
Still to come: Meaningful alternatives to certification for people who don't want to write or speak, and also, my take on the terms "Maturity" and "Discipline" in software development. Don't miss it!
Thursday, April 02, 2009
The creative tester
My latest post to the Agile-Testing List:
I heard an interesting line awhile back from James Bach; I will paraphrase him.
If I recall correctly, Bach's argument was they every time they had a
show-stopper, or even "big"-ish bug get to production, on every project, it was
never because we just ran out of time time and failed to do the next logical
test.
It was never because the team failed to automate feature X or feature Y and test
for it on this release - or that there weren't enough automated tests.
No, given an infinite amount of time with the current team and the current test
strategy, they would have failed to find the bug.
The problem with finding those bugs wasn't /time/, it was imagination - or, more
accurately, lack of imagination. That is to say, the team failed to think of
the software failing in that way. My experience tends to line up with that
statement.
If that is true, then a creative mind - creative in terms of possible failures -
something a tester should coddle, feed, and attempt to grow, right?
So - what techniques, ideas and skills do you know to encourage a creative mind?
One of my favorites is to indulge and reward my own curiosity.
regards,
--heusser
I heard an interesting line awhile back from James Bach; I will paraphrase him.
If I recall correctly, Bach's argument was they every time they had a
show-stopper, or even "big"-ish bug get to production, on every project, it was
never because we just ran out of time time and failed to do the next logical
test.
It was never because the team failed to automate feature X or feature Y and test
for it on this release - or that there weren't enough automated tests.
No, given an infinite amount of time with the current team and the current test
strategy, they would have failed to find the bug.
The problem with finding those bugs wasn't /time/, it was imagination - or, more
accurately, lack of imagination. That is to say, the team failed to think of
the software failing in that way. My experience tends to line up with that
statement.
If that is true, then a creative mind - creative in terms of possible failures -
something a tester should coddle, feed, and attempt to grow, right?
So - what techniques, ideas and skills do you know to encourage a creative mind?
One of my favorites is to indulge and reward my own curiosity.
regards,
--heusser
Wednesday, April 01, 2009
You wake up one morning and ...
Over the past eighteen months, I've slowly stopped referring to myself as a dev/tester, and, instead, now refer to myself as a tester/developer.
In other news, I'm pretty sure the universe just exploded.
In other news, I'm pretty sure the universe just exploded.
Certification - III
I wanted to write something on certification for April Fool's Day but Scott Ambler beat me to it.
(Shakes Fist at Scott!)
Actually, for something serious: In theory, I am not opposed to a skills-based certification. For example, I understand that for the Cisco Router test, they plunk you down in a networked operations center with a broken router - somewhere - and ask you to find and fix it. Now, what you do - your troubleshooting process - is a huge part of your evaluation.
Sadly, the majority of certification I see are Body-of-Knowledge and definition based. If you know the definition of fault vs. defect, of Oracle, of Test Case, and so on, you can earn the cert. That has some value, as you can meet someone else and use a sort of "short hand" and understand each other well.
What it doesn't tell is if you can actually test software.
The Agile Alliance has a similar public position on certification; that a "good" certification would be skills-based. (Read the AA position paper here.)
Sadly, I know of no such certification in the waters I swim in; instead, it seems that, for the most part, opportunists(*) define the simplest possible level of test, one that only tests the very lowest levels of Bloom's Hierarchy. Personally, I find the answer to "What is the right thing to do in this question" is usually to say "it depends, what about?" and ask a number of follow-up questions - that defies the format of the multiple-choice test.
I understand that the exam lawyers take for the bar has several pages of background information for each question and that the exam for a financial planner is similar - and instead of multiple-guess, those tests are graded as essays.
But even that wouldn't answer for certain the question "Can this person test (our) software well?"
Having a cert that did that would provide one major benefit to employers; it would allow them to outsource discernment. "Oh, he is a certified agile-tester, he must be good, we can hire him and skip the interview process."
Is that really what we want?
No, I suspect that I am in the same camp as Tom DeMarco, and, to paraphrase him, I really do believe that poor old Microsoft and poor old Google and poor old Yahoo will have to continue doing what they have always done: Decide for themselves what they want to see in technologists, and design interview systems with the intent of figuring out a yes or no. And the other programmers - the independents, the Micro ISV owners, the start-up founders - well, those guys mostly work for themselves, so a certification simply does not matter.
If you want to demonstrate that you are learning and growing professionally, and are uncomfortable writing and speaking, and for some reason don't want to make open source contributions (say you are a tester) - I suppose certification-as-a-merit-badge is one thing you can do. For example, I think this is a good, healthy way to view the Scrum Master Credential - let's just keep our perceptions of it balanced.
A serious post on April 1st. Who woulda thunk.
--heusser
(*) - And, I am sorry to say, a few others of an entirely different, good character.
(Shakes Fist at Scott!)
Actually, for something serious: In theory, I am not opposed to a skills-based certification. For example, I understand that for the Cisco Router test, they plunk you down in a networked operations center with a broken router - somewhere - and ask you to find and fix it. Now, what you do - your troubleshooting process - is a huge part of your evaluation.
Sadly, the majority of certification I see are Body-of-Knowledge and definition based. If you know the definition of fault vs. defect, of Oracle, of Test Case, and so on, you can earn the cert. That has some value, as you can meet someone else and use a sort of "short hand" and understand each other well.
What it doesn't tell is if you can actually test software.
The Agile Alliance has a similar public position on certification; that a "good" certification would be skills-based. (Read the AA position paper here.)
Sadly, I know of no such certification in the waters I swim in; instead, it seems that, for the most part, opportunists(*) define the simplest possible level of test, one that only tests the very lowest levels of Bloom's Hierarchy. Personally, I find the answer to "What is the right thing to do in this question" is usually to say "it depends, what about?" and ask a number of follow-up questions - that defies the format of the multiple-choice test.
I understand that the exam lawyers take for the bar has several pages of background information for each question and that the exam for a financial planner is similar - and instead of multiple-guess, those tests are graded as essays.
But even that wouldn't answer for certain the question "Can this person test (our) software well?"
Having a cert that did that would provide one major benefit to employers; it would allow them to outsource discernment. "Oh, he is a certified agile-tester, he must be good, we can hire him and skip the interview process."
Is that really what we want?
No, I suspect that I am in the same camp as Tom DeMarco, and, to paraphrase him, I really do believe that poor old Microsoft and poor old Google and poor old Yahoo will have to continue doing what they have always done: Decide for themselves what they want to see in technologists, and design interview systems with the intent of figuring out a yes or no. And the other programmers - the independents, the Micro ISV owners, the start-up founders - well, those guys mostly work for themselves, so a certification simply does not matter.
If you want to demonstrate that you are learning and growing professionally, and are uncomfortable writing and speaking, and for some reason don't want to make open source contributions (say you are a tester) - I suppose certification-as-a-merit-badge is one thing you can do. For example, I think this is a good, healthy way to view the Scrum Master Credential - let's just keep our perceptions of it balanced.
A serious post on April 1st. Who woulda thunk.
--heusser
(*) - And, I am sorry to say, a few others of an entirely different, good character.
Subscribe to:
Posts (Atom)