A few weeks ago I put out a post on my other blog called "The Boutique Tester"; it has received a decent amount of commentary and feedback, including a mention on the Watir Podcast.
I've got a few ideas to flesh out the details, the business model, and discuss people who come close to embodying the ideals of the Boutique Tester. The question is: Where do I put them? This blog? My other blog which focuses on testing - Creative Chaos? On one and link them back and forth?
I'm interested in your thoughts.
Friday, August 14, 2009
Thursday, April 23, 2009
"Worse is Better"
When I was new in my career, I read a lot of books about programming craft. One common theme of the books was perfectionism - and analysis paralysis. That a team would want to get the requirements (or design) "right", and so, would not actually product anything. I never saw it; I thought it was a myth.
Then I went to work for a big company. Oh. My. Goodness.
I met people who talked a great game yet, in a period of years, had never actually shipped any software. I'm talking about /nothing/. Years later, some of them are senior managers and executives. I'm still not quite sure I understand how that works. I have a clue, but that's not what this post is about.
I realized that -- somehow -- my value system was different. I wanted to get something out there, learn from it's failings, adjust it, and make it better - instead of trying to get everything right "up front." Reading things like Peopleware
or the Agile Manifesto convinced me that I was not the only person that felt this way.
The best (short) explanation of this I have ever read is "Worse Is Better" by Richard Gabriel; here is an excerpt:
I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:
* Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
* Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
* Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
* Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.
The worse-is-better philosophy is only slightly different:
* Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
* Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
* Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
* Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
Of course, you can read the entire section yourself - it's taken from a much longer paper titled LISP: The Good News, The Bad News, And How To Win Big.
Now, the mental attitude of perfectionism is entrenched; you can't just forward someone a link to a Gabriel paper and expect them to change their attitude or behavior. Asking them to change behavior would be, in effect, asking them to change their value system.
The one approach I have had some success with is waiting six months and asking "So, how's that working for you?" then asking how long it would take if the team just ... did it and adjusted?
It's hard to argue for six more months of designing the process for a reporting and analysis package when you could create the reports and put them in the hands of the customer in less than a month.
Failing at that, I talk about fail fast, lean thinking, and waste.
UPDATE: I've found that one section I quoted, treated historically, to be a some of the greatest prose ever written on software development dynamics. Jamie Zawinski, the creator of Netscape Navigator, quotes just that section on his website. Certainly, the LISP folks actually shipped things. I did not mean to compare them to other people of a different character who were /totally/ stuck in analysis paralysis.
Then I went to work for a big company. Oh. My. Goodness.
I met people who talked a great game yet, in a period of years, had never actually shipped any software. I'm talking about /nothing/. Years later, some of them are senior managers and executives. I'm still not quite sure I understand how that works. I have a clue, but that's not what this post is about.
I realized that -- somehow -- my value system was different. I wanted to get something out there, learn from it's failings, adjust it, and make it better - instead of trying to get everything right "up front." Reading things like Peopleware
or the Agile Manifesto convinced me that I was not the only person that felt this way.The best (short) explanation of this I have ever read is "Worse Is Better" by Richard Gabriel; here is an excerpt:
I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right:
* Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.
* Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed.
* Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.
* Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.
I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation.
The worse-is-better philosophy is only slightly different:
* Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
* Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
* Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
* Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach.
However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach.
Of course, you can read the entire section yourself - it's taken from a much longer paper titled LISP: The Good News, The Bad News, And How To Win Big.
Now, the mental attitude of perfectionism is entrenched; you can't just forward someone a link to a Gabriel paper and expect them to change their attitude or behavior. Asking them to change behavior would be, in effect, asking them to change their value system.
The one approach I have had some success with is waiting six months and asking "So, how's that working for you?" then asking how long it would take if the team just ... did it and adjusted?
It's hard to argue for six more months of designing the process for a reporting and analysis package when you could create the reports and put them in the hands of the customer in less than a month.
Failing at that, I talk about fail fast, lean thinking, and waste.
UPDATE: I've found that one section I quoted, treated historically, to be a some of the greatest prose ever written on software development dynamics. Jamie Zawinski, the creator of Netscape Navigator, quotes just that section on his website. Certainly, the LISP folks actually shipped things. I did not mean to compare them to other people of a different character who were /totally/ stuck in analysis paralysis.
Sunday, April 5, 2009
Monday, March 30, 2009
Low Quality Software
I just made the following post to the Software Craftsmanship Google Group:
On Mar 29, 11:11 pm, Klaus Hebsgaard wrote:
> I totally agree, but for us in this mailinglist it is very clear what
> craftmanship is, and why it is good.
> But most people don't understand that there is high quality and low quality
> software.
++;
If I go to wall-mart and buy a low-quality shirt - sure, it may look a little odd and a button may fall off, but, for the past, I can wear it, and it is suitable as clothing.
If I buy wall-mart quality /software/, on the other hand, the risk is that it simply does not work.
I'm fond of this quote, by John Ruskin:
"It's unwise to pay too much - but it's worse to pay too little. When you pay too much you lose a little money, that is all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing you bought it to do. The common law of business balance prohibits paying a little and getting a lot. It can't be done. If you deal with the lowest bidder, it's well to add something for the risk you run. And if you do that, you will have enough to pay for something better!"
--heusser
On Mar 29, 11:11 pm, Klaus Hebsgaard
> I totally agree, but for us in this mailinglist it is very clear what
> craftmanship is, and why it is good.
> But most people don't understand that there is high quality and low quality
> software.
++;
If I go to wall-mart and buy a low-quality shirt - sure, it may look a little odd and a button may fall off, but, for the past, I can wear it, and it is suitable as clothing.
If I buy wall-mart quality /software/, on the other hand, the risk is that it simply does not work.
I'm fond of this quote, by John Ruskin:
"It's unwise to pay too much - but it's worse to pay too little. When you pay too much you lose a little money, that is all. When you pay too little, you sometimes lose everything, because the thing you bought was incapable of doing the thing you bought it to do. The common law of business balance prohibits paying a little and getting a lot. It can't be done. If you deal with the lowest bidder, it's well to add something for the risk you run. And if you do that, you will have enough to pay for something better!"
--heusser
Friday, March 6, 2009
Development Katas
As many people in the software craft movement have pointed out, it's very hard to focus on reflective improvement while you are coding. In fact, the nature of your work (maintenance, time pressure) may make it hard to develop specific skills like design or clarity of code.
So why not do specific exercises outside of work, designed with the intent to sharpen our thinking - perhaps in public under scrutiny?
Micah Martin has proposed such "katas", based on martial arts. It's interesting stuff and there's video.
What are your favorite developer (or maybe test) katas? I intend to make a list.
So why not do specific exercises outside of work, designed with the intent to sharpen our thinking - perhaps in public under scrutiny?
Micah Martin has proposed such "katas", based on martial arts. It's interesting stuff and there's video.
What are your favorite developer (or maybe test) katas? I intend to make a list.
Friday, February 13, 2009
Robert C. Martin On Craft
We invited "UncleBob" Martin to GLSEC last year, to give his talk on Ethics and Craftsmanship as the opening keynote.
If you missed it, well, you missed out. However, Bob recently gave the talk at JAOO and it was recorded; you can watch the video right now on infoq.com for free. Enjoy.
If you missed it, well, you missed out. However, Bob recently gave the talk at JAOO and it was recorded; you can watch the video right now on infoq.com for free. Enjoy.
Wednesday, February 11, 2009
Outliers - III
Last Month I mentioned the great body of literature on airline crashes and how they happen. The problems are similar to ones we experience in business: The project is late, the staff is working too hard and taking shortcuts - management applies pressure, and a series of not-that-bad-by-themselves mistakes builds up until, eventually, you get a crash.
What's interesting is that the pilot is not working in isolation. On any commercial flight, the pilot will have someone qualified, albeit junior, sitting next to him - the co-pilot. What the co-pilot is responsible for, exactly, is a matter of philosophy. Some people view the co-pilot as sort of a double-checker; others view him as merely a body-double to fly the plane in case the pilot is somehow incapacitated. In the US, we typically go for the former, and it turns out this distinction is extremely important.
You see (obviously), when you have someone actively engaged in checking your work, few errors get through. We see this in software development, too, we call it "pair programming."
Notice I said that the pilot is junior. Now the issue of culture really begins to set in, because some cultures insist on deference from juniors.
So how can you, as a junior, express deference, but also point out that the pilot is making a mistake, that we are about to fly into a rainstorm and that our radar is on the fritz?
It turns out you use something called mitigating speech. In outliers, Gladwell uses the example of your boss asking you to do something over the weekend, verses your asking him.
In some places in North America, your boss might just swing by your cubical at 4:30PM on Friday and say "I need this on my desk monday morning." But if the tables were turned -- if you needed him to approve some document and send an email, you'd say "hey, boss, if it isn't too much trouble, could you take a look at this over the weekend and email your approval? That'd be great."
You're using mitigated speech. Gladwell lists six different levels of speech, from Command ("Deviate thirty degrees right") to Obligation ("I think we need to turn right") to suggestion ("maybe we should turn right") to query ("which direction would you like to deviate?) to preference and finally, to hint: "That return at twenty-five miles looks mean."
Yet, to the casual listener, mitigated and "no big deal" sound exactly the same.
So you try really really really hard to express deference "hey boss, could you please maybe think about" - in the hope that you'll be a team player - and nothing happens. Nothing changes. The boss thought it was no big deal.
This is especially problematic in high-ceremony cultures, where the decision has already been made behind closed doors. The boss would lose face to change the policy, and, besides, Joe's a team player - it's no big deal.
Until you run into the broad side of the mountain.
This isn't just speculation; countries that have a strong culture of deference have, historically, had a great many more aircraft accidents. On the order of seven times as many.
In avionics circles, the solution is something called "Crew Resource Management", which Gladwell explains is designed to give the crew the skills to communicate assertively, including specific ways to escalate if the boss isn't getting the hint. The fundamental assumption in Crew Resources Management is that we are going to make mistakes, and need to be vigilant to check and correct each other.
The basic escalation pattern is:
"Captain, I'm concerned about"
"Captain, I am uncomfortable with"
"Captain, I believe the situation is unsafe."
Before you weigh in on a subject, ask yourself how your mitigating language could be mis-understood as "no big deal." And, if it's an ethical or moral issue and the other person isn't getting it, consider escalation language.
It might not make you friends, but you might just avoid the cliff.
What's interesting is that the pilot is not working in isolation. On any commercial flight, the pilot will have someone qualified, albeit junior, sitting next to him - the co-pilot. What the co-pilot is responsible for, exactly, is a matter of philosophy. Some people view the co-pilot as sort of a double-checker; others view him as merely a body-double to fly the plane in case the pilot is somehow incapacitated. In the US, we typically go for the former, and it turns out this distinction is extremely important.
You see (obviously), when you have someone actively engaged in checking your work, few errors get through. We see this in software development, too, we call it "pair programming."
Notice I said that the pilot is junior. Now the issue of culture really begins to set in, because some cultures insist on deference from juniors.
So how can you, as a junior, express deference, but also point out that the pilot is making a mistake, that we are about to fly into a rainstorm and that our radar is on the fritz?
It turns out you use something called mitigating speech. In outliers, Gladwell uses the example of your boss asking you to do something over the weekend, verses your asking him.
In some places in North America, your boss might just swing by your cubical at 4:30PM on Friday and say "I need this on my desk monday morning." But if the tables were turned -- if you needed him to approve some document and send an email, you'd say "hey, boss, if it isn't too much trouble, could you take a look at this over the weekend and email your approval? That'd be great."
You're using mitigated speech. Gladwell lists six different levels of speech, from Command ("Deviate thirty degrees right") to Obligation ("I think we need to turn right") to suggestion ("maybe we should turn right") to query ("which direction would you like to deviate?) to preference and finally, to hint: "That return at twenty-five miles looks mean."
Yet, to the casual listener, mitigated and "no big deal" sound exactly the same.
So you try really really really hard to express deference "hey boss, could you please maybe think about" - in the hope that you'll be a team player - and nothing happens. Nothing changes. The boss thought it was no big deal.
This is especially problematic in high-ceremony cultures, where the decision has already been made behind closed doors. The boss would lose face to change the policy, and, besides, Joe's a team player - it's no big deal.
Until you run into the broad side of the mountain.
This isn't just speculation; countries that have a strong culture of deference have, historically, had a great many more aircraft accidents. On the order of seven times as many.
In avionics circles, the solution is something called "Crew Resource Management", which Gladwell explains is designed to give the crew the skills to communicate assertively, including specific ways to escalate if the boss isn't getting the hint. The fundamental assumption in Crew Resources Management is that we are going to make mistakes, and need to be vigilant to check and correct each other.
The basic escalation pattern is:
"Captain, I'm concerned about"
"Captain, I am uncomfortable with"
"Captain, I believe the situation is unsafe."
Before you weigh in on a subject, ask yourself how your mitigating language could be mis-understood as "no big deal." And, if it's an ethical or moral issue and the other person isn't getting it, consider escalation language.
It might not make you friends, but you might just avoid the cliff.
Subscribe to:
Posts (Atom)
