About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2006.Mar.04 Sat
Quote from Creating Passionate Users/How to be an Expert:
Most of us want to practice the things we're already good at, and avoid the things we suck at. We stay average or intermediate amateurs forever.
Yet the research says that if we were willing to put in more hours, and to use those hours to practice the things that aren't so fun, we could become good. Great. Potentially brilliant.
Check it out
Satir Change Model and Competency
"Unconsciously Incompetent" = Late Status Quo
(missing) = Foreign Element
(missing) = Resistance
"Consciously Incompetent" = Chaos
(missing) = Transforming Idea
"Consciously Competent" = Integration
"Unconsciously Competent" = New Status Quo
See Steven M. Smith's paper on the Satir Change Model. The "Unconsciously Incompetent, etc." meme is all over the web, but I'm not aware of a definitive source.
Using the above with my experience with test-driven-development. Before I encountered XP, I was in the Late Status Quo. I had never done TDD - hadn't even heard of it. I had had the experience of writing unit tests after-the-fact, and it wasn't pleasant. The fact that many studies and experience reports indicated that thorough unit testing decreases bug-rates (and bug reoccurrences) by 60% or more wasn't impacting my consciousness very much. Since I wasn't even doing TDD, I was "Unconsciously Incompetent".
Then I heard about XP and TDD and read some pretty amazing stuff by or about Kent Beck, Ward Cunningham, Robert Martin, Ron Jeffries, et alia. I had already encountered these people ("virtually") in newsgroups on object-oriented-programming, books on design patterns, and so on, so they had earned my respect already. This was the Foreign Element that triggered the change process that would get me out of the Late Status Quo. If these smart, impressive, guys were finding TDD to be so productive that they never wanted to go back to traditional programming techniques again, maybe it could help me, as well.
So I tried TDD. It was hard to break my habit of writing the code first. (Sometimes it still is). I sometimes wrote too-big tests, or too-big blocks of code to make the tests pass. I learned later that TDD is easier in a pair programming situation (you have someone to help come up with tests or ideas on what code to write to pass the tests), but my initial TDD experiences were solo. This was the Chaos stage, and I was "Consciously Incompetent".
Various books and examples on the web provided me with techniques on TDD. How to write really small tests. How to write really small pieces of code to pass the tests. How to use Mock Objects to enable staying focused on one class. (The "mock" class is an object that the class-under-test collaborates with, and may not even exist in a 'real' form yet. If you want to get picky, there are "Fake" and "Stub" and other flavors of test-assisting-objects similar to but different than "Mock" objects.) These and other resources on refactoring and code smells were Transforming Ideas that helped me Integrate TDD into my repertoire of programming techniques. I became "Consciously Competent". I began to experience the benefits of TDD: cleaner designs, regression tests (that were not painful to develop), no longer spending so much time manually testing through the GUI or stepping through code with the debugger. I could make a change, run the tests, and get a quick failure or success indication.
I no longer have to invent/learn "from scratch" when doing test-driven development, so I could be in the New Status Quo. I'm comfortable with the process, including modifying the test framework to support new testing needs as they come up. However, I don't like to think that I'm in the "Unconsciously Competent" stage. TDD doesn't work if you don't think about what and how you're doing what you're doing. If you don't think when you're doing TDD, you can end up with lots of trivial tests and duplicated code to pass the tests. After you've cleaned up a few messes that came from not thinking, you learn to keep your brain turned on. A pair programming partner helps in that they can challenge your assumptions. And there are always new challenges, areas I haven't yet attempted in TDD: Cocoa UI, for example.
Consciousness is not just a good idea, it's a way of life. :-)