Extreme Programming in Japan?
You've got to see this video.
Don't worry, it has subtitles, and it's only three minutes long.
Friday, December 08, 2006
Thursday, December 07, 2006
A few of my favorite things - III
I promise to talk about testing tools, so next up is a Digital
Voice Recorder with PC Link. This particular model records and transfers to PC in WAV format, which can be converted to MP3 with any tool such as Audacity.
Here's the backstory:
When I started by career, occasionally I heard decisions that didn't seem to make sense that would require code change. Several times I put comments in the code like this:
//On 12/20/1997, Bob Smith directed that
//the HMO and PPO business
//should be treated identically
//for purposes of BAH.
Of course, six months later, some one would ask why we were treating HMO and PPO the same, and it wouldn't be in the requirements, and I would dig out that comment.
That never helped me. Ever. Really - Bob would say "Gee, I don't remember telling you that" and nothing would change. I would still have to change the code, and the department still had "Egg on it's face." (Or some other analogy)
About a year ago I got a voice recorder to record presentations and podcasts and such, but I started using them as a requirements technique about nine months ago. At the beginning of the meeting, I make it clear that the purpose of the recorder is for my own notes, that I will *NOT* be using the recordings as a conversation. At the end of the conversation, if we have changed a policy, I turn the recorder on again and do a formal one, where we have a short discussion about the change, the pros and cons, the final decision, and who is involved. I ask "Do I have the right decision makers in the room?" and get verbal agreement.
THAT recording gets checked into version control, right next to the requirements doc.
Those kinds of discussion are easy to capture, easy to throw away, and I have found that anyone in the room can use a voice recorder - regardless of title.
But here's the secret - even if I promise to throw away the notes, we behave differently when we know we are being recorded. We tend to think things through a little bit more and come to a better decision.
That is the real purpose of the device; not as a CYA tool when someone makes a bad off-the-cuff decision, but as a prevention technique, to make sure we make the right decision in the first place.
Now that is worth the seventy bucks.
Voice Recorder with PC Link. This particular model records and transfers to PC in WAV format, which can be converted to MP3 with any tool such as Audacity.
Here's the backstory:
When I started by career, occasionally I heard decisions that didn't seem to make sense that would require code change. Several times I put comments in the code like this:
//On 12/20/1997, Bob Smith directed that
//the HMO and PPO business
//should be treated identically
//for purposes of BAH.
Of course, six months later, some one would ask why we were treating HMO and PPO the same, and it wouldn't be in the requirements, and I would dig out that comment.
That never helped me. Ever. Really - Bob would say "Gee, I don't remember telling you that" and nothing would change. I would still have to change the code, and the department still had "Egg on it's face." (Or some other analogy)
About a year ago I got a voice recorder to record presentations and podcasts and such, but I started using them as a requirements technique about nine months ago. At the beginning of the meeting, I make it clear that the purpose of the recorder is for my own notes, that I will *NOT* be using the recordings as a conversation. At the end of the conversation, if we have changed a policy, I turn the recorder on again and do a formal one, where we have a short discussion about the change, the pros and cons, the final decision, and who is involved. I ask "Do I have the right decision makers in the room?" and get verbal agreement.
THAT recording gets checked into version control, right next to the requirements doc.
Those kinds of discussion are easy to capture, easy to throw away, and I have found that anyone in the room can use a voice recorder - regardless of title.
But here's the secret - even if I promise to throw away the notes, we behave differently when we know we are being recorded. We tend to think things through a little bit more and come to a better decision.
That is the real purpose of the device; not as a CYA tool when someone makes a bad off-the-cuff decision, but as a prevention technique, to make sure we make the right decision in the first place.
Now that is worth the seventy bucks.
Test Estimation
I thought my recent post to the Agile-Testing Discussion list was worth repeating. Here goes:
Earlier, Lisa Crispin said Test Estimation was hard, and asked if anyone had a perfect method, to which I replied:
> Ask the customer when they want it done, get a prioritized list of
> features, and deliver on the day they asked for it?
And she asked:
>...and how will we know how many of these features we will be
>able to deliver in a given period of time?
>
We don't. Why pretend we do?
There's a slippery slope between asking for good faith estimates ("Knowing what you know now, when do you think you can deliver?") and predicting the future.
Assuming the customer will change his or her mind about what they need, if I deliver running tested features periodically (say, every 30 days), then, ultimately, it's the customer's decision if what we have now is good enough or not. Let them pick the date.
That I can do. The crystal ball thing? Not so much. I think the best I've seen is to use velocity with yesterday's weather, or using traditional functional decompostion methods combined with Critical Chain Project Management. (I cover this a little bit in a talk I gave in Indianapolis last year - here - http://xndev.blogspot.com/2006/10/but-dont-take-my-word-for-it.html )
Earlier, Lisa Crispin said Test Estimation was hard, and asked if anyone had a perfect method, to which I replied:
> Ask the customer when they want it done, get a prioritized list of
> features, and deliver on the day they asked for it?
And she asked:
>...and how will we know how many of these features we will be
>able to deliver in a given period of time?
>
We don't. Why pretend we do?
There's a slippery slope between asking for good faith estimates ("Knowing what you know now, when do you think you can deliver?") and predicting the future.
Assuming the customer will change his or her mind about what they need, if I deliver running tested features periodically (say, every 30 days), then, ultimately, it's the customer's decision if what we have now is good enough or not. Let them pick the date.
That I can do. The crystal ball thing? Not so much. I think the best I've seen is to use velocity with yesterday's weather, or using traditional functional decompostion methods combined with Critical Chain Project Management. (I cover this a little bit in a talk I gave in Indianapolis last year - here - http://xndev.blogspot.com/2006/10/but-dont-take-my-word-for-it.html )
Wednesday, December 06, 2006
A Few Of My Favorite Things - II
If you watch enough presentations, you start to see things that detract from the message. The speaker has to plug in, power up, and press control-shift-F9 a bunch of times. He has to try to make smalltalk in this period - smalltalk that he didn't expect to do. During the talk, he may have to turn around to face the screen (away from the audience) to read the bullet points. Another annoyance is when the speaker only reads the bullet points; the information tends to come out clipped and awkward. (See Peter Norvig's hypothetical If Lincoln had PowerPoint for an example)
My take on that is that if all the speaker is going to do is read the bullet points, I might as well have downloaded the powerpoint from his website and saved the conference fee.
More than annoyances, some things just cause an awkward pause in the discussion. Drinking a glass of water can be natural, but powerpoint forces some things, like slide transitions, to be awkward. The speaker finishes his thought and has to walk over to the laptop, click the down button, and check to see if it worked; or worse yet, spend the entire talk in front of the podium to avoid that problem.
Or, for fifty bucks, you could get a
Wireless Presenter
and advanced slides where-ever you like.
That particular model comes with a laster pointer; mine doesn't have the laser pointer, but they can be helpful and you only save ten bucks by skipping that.
Or course, when I use these, I turn my head to verify that the slide worked, but that's about it. Occasionally, I have accidentally advanced a slide when I didn't want to, and not noticed it until later.
Still, it's a tool that helps make the presentation seamless, and it's cheap and small, and it's not a trick or manipulation.
That's enough presentation tools for now. Tomorrow: Testing tools ...
My take on that is that if all the speaker is going to do is read the bullet points, I might as well have downloaded the powerpoint from his website and saved the conference fee.
More than annoyances, some things just cause an awkward pause in the discussion. Drinking a glass of water can be natural, but powerpoint forces some things, like slide transitions, to be awkward. The speaker finishes his thought and has to walk over to the laptop, click the down button, and check to see if it worked; or worse yet, spend the entire talk in front of the podium to avoid that problem.
Or, for fifty bucks, you could get a
Wireless Presenter
and advanced slides where-ever you like.That particular model comes with a laster pointer; mine doesn't have the laser pointer, but they can be helpful and you only save ten bucks by skipping that.
Or course, when I use these, I turn my head to verify that the slide worked, but that's about it. Occasionally, I have accidentally advanced a slide when I didn't want to, and not noticed it until later.
Still, it's a tool that helps make the presentation seamless, and it's cheap and small, and it's not a trick or manipulation.
That's enough presentation tools for now. Tomorrow: Testing tools ...
Canary in a Coal Mine
There is an interesting talk in Info.com by Ken Schwaber.
Ken is a co-author of the agile manifesto and co-inventor of Scrum.
If you don't want to listen for an hour, move the slider to 29 minutes - the section on magic thinking and lies. If you get hooked, you can come back to the first 29 minutes later.
Of course, if your organization doesn't have problems with scheduling and politics, you won't need this.
Ken is a co-author of the agile manifesto and co-inventor of Scrum.
If you don't want to listen for an hour, move the slider to 29 minutes - the section on magic thinking and lies. If you get hooked, you can come back to the first 29 minutes later.
Of course, if your organization doesn't have problems with scheduling and politics, you won't need this.
Tuesday, December 05, 2006
A few of my favorite things - I
I'd like to start a short series on my favorite tools. No fluff, just stuff.
Tool #1: Google Reader. This is like TiVo for blogs. You search for, find, and list your favorite blogs, and it updates itself with a GMail like interface when new posts come out. Because Google indexs, well, everything, you can have it notify you when any website changes.
If you've avoided using an RSS-feed reader because they can be annoying or weren't mature yet, try Gooder Reader.
Of course, it is free.
Tool #1: Google Reader. This is like TiVo for blogs. You search for, find, and list your favorite blogs, and it updates itself with a GMail like interface when new posts come out. Because Google indexs, well, everything, you can have it notify you when any website changes.
If you've avoided using an RSS-feed reader because they can be annoying or weren't mature yet, try Gooder Reader.
Of course, it is free.
Throughput - I
I've been thinking about throughput a lot lately.
Example: It's winter in Michigan, and it's snowing. So, on my way to work this morning, I see a truck that is plowing. The truck is doing an excellent job of plowing, shifting from forward to reverse very quickly, accelerating quickly and using heavy brakes. He sure is marching and moving.
The problem was, I was trying to get past him, and I couldn't, because his sudden shifts in momentum were so uprupt that it would be dangerous to pull forward. I had to wait. And wait.
So, the truck was doing an excellent job plowing, but overall throughput on the road suffered.
We do this in software development all the time. We optimize the job for our role, focus on handoffs, signatures, and role-based contracts, instead of trying to be helpful and collaborate. Devs refuse to proceed without documented requirements instead of having a conversation and trying to figure out what the customers and analysts desire. Architects (and I use the term loosely) refuse to begin design until "all" the requirements are elaborated. Testers refuse to begin testing until all the documentation is completed.
Each of these tactics helps the individual role be efficient (or easy), but the overall project suffers. In fact, you can make a strong argument that the Waterfall model gained it's popularity not because it was good, but because it is conveinient and easy for management. (After all, for the schedule, you can just "set it and forget it.")
In my own career, in general, I've protected the project at my own expense. While I have taken some slings and arrows (and been told at least twice to "know your role, be your role" when I was trying to be helpful and get things done) it's led to more successful projects, and allow me to develop expertise in software testing, requirements, scheduling, and the overall process.
A rising tide lifts all boats, so I would like to submit this to you: Forget your role, keep the project moving, and your title and position might just take care of itself.
(Of course, there's more to it than that. More later.)
Example: It's winter in Michigan, and it's snowing. So, on my way to work this morning, I see a truck that is plowing. The truck is doing an excellent job of plowing, shifting from forward to reverse very quickly, accelerating quickly and using heavy brakes. He sure is marching and moving.
The problem was, I was trying to get past him, and I couldn't, because his sudden shifts in momentum were so uprupt that it would be dangerous to pull forward. I had to wait. And wait.
So, the truck was doing an excellent job plowing, but overall throughput on the road suffered.
We do this in software development all the time. We optimize the job for our role, focus on handoffs, signatures, and role-based contracts, instead of trying to be helpful and collaborate. Devs refuse to proceed without documented requirements instead of having a conversation and trying to figure out what the customers and analysts desire. Architects (and I use the term loosely) refuse to begin design until "all" the requirements are elaborated. Testers refuse to begin testing until all the documentation is completed.
Each of these tactics helps the individual role be efficient (or easy), but the overall project suffers. In fact, you can make a strong argument that the Waterfall model gained it's popularity not because it was good, but because it is conveinient and easy for management. (After all, for the schedule, you can just "set it and forget it.")
In my own career, in general, I've protected the project at my own expense. While I have taken some slings and arrows (and been told at least twice to "know your role, be your role" when I was trying to be helpful and get things done) it's led to more successful projects, and allow me to develop expertise in software testing, requirements, scheduling, and the overall process.
A rising tide lifts all boats, so I would like to submit this to you: Forget your role, keep the project moving, and your title and position might just take care of itself.
(Of course, there's more to it than that. More later.)
Monday, December 04, 2006
Why Blog?
So far, I'm obligated for quite a bit ...
A) I want to describe blue man group, and how that might impact our communcation
B) Discuss possible ways to contribute to software development, and then what I plan on doing next (my next big thing)
C) I'd like to talk about why I'm blogging, and why you might want to read it
D) I want to talk about the cult of stability in software development
... and other interesting things keep coming up that delay that.
So, anyway, something interesting happened to me today. Luckily, it ties in with (C).
My main goal of the blog is to cover some new ground - to talk about some things that aren't in the text books yet are important. Yes, virginia, there really is career advice beyond silly cliches and Going Into Management. Yes, writing and communicating is extremely important in software development; in fact, it's a skill, and it can be improved with effort, direction, peer norms, and advice.
Yes, it is possible to run a software conference, speak at one, or write a magazine article. The process of coming up with ideas and running events shouldn't be shrouded in mystery; instead, I'd like to write about that.
The same goes for the dynamics of what actually happens on software projects.
So, here's the interesting thing that happened to me: Addison-Wesley asked me to review eight chapters of a book proposal. It's a book in the review process; they've essentially asked the author to write a first draft and he turned it in.
I asked AW if I could blog about the experience, and they said yes.
So - would you like to find out what it's like to review book proposals? I've placed two chapters on the web; one of the ones that I felt was strong and one of the weaker ones. They are chapter 0 (the introduction or preface) and chapter 4 ("the right stuff") - The book is on teamwork in software development and the author is Jim Brosseau.
The chapters are here and here.
We could do this double-blind and compare notes. If you're really interested, let me know, I'll throw up the book reviewer form or something.
...
Whew. Long, rambling post, but of the four things I'd like to do, I hope I just covered (C) ....
A) I want to describe blue man group, and how that might impact our communcation
B) Discuss possible ways to contribute to software development, and then what I plan on doing next (my next big thing)
C) I'd like to talk about why I'm blogging, and why you might want to read it
D) I want to talk about the cult of stability in software development
... and other interesting things keep coming up that delay that.
So, anyway, something interesting happened to me today. Luckily, it ties in with (C).
My main goal of the blog is to cover some new ground - to talk about some things that aren't in the text books yet are important. Yes, virginia, there really is career advice beyond silly cliches and Going Into Management. Yes, writing and communicating is extremely important in software development; in fact, it's a skill, and it can be improved with effort, direction, peer norms, and advice.
Yes, it is possible to run a software conference, speak at one, or write a magazine article. The process of coming up with ideas and running events shouldn't be shrouded in mystery; instead, I'd like to write about that.
The same goes for the dynamics of what actually happens on software projects.
So, here's the interesting thing that happened to me: Addison-Wesley asked me to review eight chapters of a book proposal. It's a book in the review process; they've essentially asked the author to write a first draft and he turned it in.
I asked AW if I could blog about the experience, and they said yes.
So - would you like to find out what it's like to review book proposals? I've placed two chapters on the web; one of the ones that I felt was strong and one of the weaker ones. They are chapter 0 (the introduction or preface) and chapter 4 ("the right stuff") - The book is on teamwork in software development and the author is Jim Brosseau.
The chapters are here and here.
We could do this double-blind and compare notes. If you're really interested, let me know, I'll throw up the book reviewer form or something.
...
Whew. Long, rambling post, but of the four things I'd like to do, I hope I just covered (C) ....
Friday, December 01, 2006
Agile Metrics
Someone on the Agile-Testing list asked about test metrics for his SEI/CMM compliance effort. Here's my reply:
I have one graph, which is a stacked-line graph. On the X axis I have time. On the Y axis I have deliverables.
Each deliverable has phases - need requirements, in dev, in software engineering test, in customer acceptance test, waiting for prod, and in production.
I update the chart every monday. Of course, I am an agile guy, so I dev as I test, so spending a lot of time in SE test tells me something. (If I move to SE test on tuesday and promote to CA test the next day, it never shows up on the spreadsheet. That's good.)
Looking at this sheet, I should see the size of the delivered features go up regularly. Now that is what I care about. It also shows the relative size of the work-in-progress inventory.
It helps the devs. The testers. The requirements people ... and it's holistic.
Now, if I see things start to stack up at a specific point, (especially testing), I know something is going on, and I put more effort in eliminating the bottleneck; that's basic constraint theory.
Of course, it's a first-order approximation. Some deliverables are done in a few days, others are a few weeks. I could weight them, but that seems like 'good enough' for now. Of course, the graph tells a story, so I show it to people in context only.
That has nothing to do with the CMM(I) - it's what I actually do to make my life easier. It has pros and cons, but it gives me and my management visibility into what I am producing, and opportunities for feedback.
As for the CMM(I):
I just spent a considerable amount of time reviewing the CMM(I) Integrated Version 1.1 for Systems Engineering and Software Engineering, looking for a tie between metrics and testing.
I couldn't find it. Of course, the thing is so poorly written that it's probably in there.
The one thing I did find was that for level 4, it could be argued that you need to measure your adherance to the defined process. ("Quantitative Project Management"). Now that is relatively easy, and counting test cases doesn't help you get there, unless you have a standard policy of X test cases per 100 lines of code, or something like that.
I don't know your environment, but in mine, I would want a CMM(I) assessor who believed that our environment changes so rapidly that common approaches to test metrics would be nieve and premature, and that we could get all of the level 4 goals accomplished without them. (Ref: Handbook of SQA, 3rd ed, Schulmeyer/McManus)
But, to be honest, I have fundamental problems with the CMMI. I suspect that you might be better off reading "Quality is Free" for yourself.
So please take this with a grain of salt. I did a best-effort attempt at a answering your question, but my head hurts now.
Good Luck.
I have one graph, which is a stacked-line graph. On the X axis I have time. On the Y axis I have deliverables.
Each deliverable has phases - need requirements, in dev, in software engineering test, in customer acceptance test, waiting for prod, and in production.
I update the chart every monday. Of course, I am an agile guy, so I dev as I test, so spending a lot of time in SE test tells me something. (If I move to SE test on tuesday and promote to CA test the next day, it never shows up on the spreadsheet. That's good.)
Looking at this sheet, I should see the size of the delivered features go up regularly. Now that is what I care about. It also shows the relative size of the work-in-progress inventory.
It helps the devs. The testers. The requirements people ... and it's holistic.
Now, if I see things start to stack up at a specific point, (especially testing), I know something is going on, and I put more effort in eliminating the bottleneck; that's basic constraint theory.
Of course, it's a first-order approximation. Some deliverables are done in a few days, others are a few weeks. I could weight them, but that seems like 'good enough' for now. Of course, the graph tells a story, so I show it to people in context only.
That has nothing to do with the CMM(I) - it's what I actually do to make my life easier. It has pros and cons, but it gives me and my management visibility into what I am producing, and opportunities for feedback.
As for the CMM(I):
I just spent a considerable amount of time reviewing the CMM(I) Integrated Version 1.1 for Systems Engineering and Software Engineering, looking for a tie between metrics and testing.
I couldn't find it. Of course, the thing is so poorly written that it's probably in there.
The one thing I did find was that for level 4, it could be argued that you need to measure your adherance to the defined process. ("Quantitative Project Management"). Now that is relatively easy, and counting test cases doesn't help you get there, unless you have a standard policy of X test cases per 100 lines of code, or something like that.
I don't know your environment, but in mine, I would want a CMM(I) assessor who believed that our environment changes so rapidly that common approaches to test metrics would be nieve and premature, and that we could get all of the level 4 goals accomplished without them. (Ref: Handbook of SQA, 3rd ed, Schulmeyer/McManus)
But, to be honest, I have fundamental problems with the CMMI. I suspect that you might be better off reading "Quality is Free" for yourself.
So please take this with a grain of salt. I did a best-effort attempt at a answering your question, but my head hurts now.
Good Luck.
On Leadership
Pollyanna Pixton Asked me how my thoughts on leadership came to be. Here's a quick braindump:
>How did your thoughts evolve?
Now _that_ is an interesting question!
I spent seven years as a Civil Air Patrol Cadet while also reading the military science and science fiction success literature - especially Robert Heinlein.
You can learn a bit about that part of my life by checking out my amazon listmania lists:
https://www.amazon.com/gp/pdp/profile/A1MQIGB1G0X1ZA/103-6394374-2847053
During my time as a cadet, I mostly sought leadership ("command") positions; I desired power and position. We used to have these summer encampments where we "beat down" the first year cadets and then "built them back up in our image" - I never agreed with that model. Instead of summer encampment, the summer I was seventeen I went through real US Army Basic Training (In the Reserve), and realized there was a lot more too it than that. It's something between naive and just plain wrong to assume that a bunch of teenagers can do in a week what takes professional, trained drill sergeants do in two months.
Oh, and fear is a crappy motivator.
The following summer in staff training, I stood up and said "I think we're doing this wrong. Shouldn't our goal be to inspire cheerful and willing obedience to orders?"
Yes, it was a cliche, but that was good - half the room had heard the term before. The attitude of that encampment was split about 50/50, but I'm proud of what we did that year.
At 20 I became a professional programmer, and at 22 accepted a commission as an officer in the Civil Air Patrol. As an adult, my role changed from executive to advisor, coach, and mentor to cadets. About this time I realized that command was no test of leadership; people were expected to obey orders. Instead of seeking command positions where people had to listen to me, I sought staff positions where people had the option of ignoring me. That way, I had to develop my influence skills.
Professionally, I graduated with a Math degree and a concentration in Computer Science, not a CS degree, so I felt insecure about my skills, so I read every book I could find on development and methodology to "catch up." Eventually, I found that I knew more than the guy next to me, but I was still "Wrong" because I didn't get it; I kept going for this simple, elegant solutions instead of developing robust, reusable frameworks. I kept arguing for developing features in slices and saying that our crystal ball was wrong; every time we spent 6 months developing an extensible framework, the customer would request a new feature and we'd say "Gee, we never thought of that. THAT possibility isn't in our extensible framework ..."
Clearly, I didn't get it, so I went back to school at night and earned an MS in Computer Information Systems. About this time, I was studying Eli Goldratt, Alfhie Kohn, John P. Kotter, Michael Porter, Ed Yourdon, Steve McConnell, and Ron Jeffries. When I found extreme programming I about blew a gasket. :-)
Oh, I read Fred Taylor and Peter Drucker, and realized that the command and control structures in the typical North American company are based on an out-moded, anti-intellectual-for-workers approach that Taylor developed for European Immigrants in the early 1900's. The typical employee of his first study had, on average, a 3rd Grade Education - typically in German. Just like Drucker said, today's white collar worker is better educated and has a larger scope of responsibility than the 2nd-level supervisor of 1910.
After that, I started studying Jerry Weinberg and General Systems thinking. When I graduated, I found that I had developed a habit of spending ten hours a week on professional development, and just kept at it, turning that time into writing, speaking, and consulting.
Which takes us to today. I view software development as intellectually challenging, creative work. I am interested in two forms of innovation - upstream (ideas to improve the product) and downstream (ideas to change and improve the process.)
My curent bugabo is Traditional "process improvement" models that focus on creating stable, predictable, repeatable systems, or the focus on implementing a complete spec. My software projects are all different; trying to be repeatable when you are doing different things doesn't make sense to me. And the focus on the complete spec over collaboration eliminates my ability to do upstream innovation.
After fifteen years of feeling insecure about my skills and being patted on the head, told that one day I will "get it", I'm beginning to believe that it is in fact the Cult Of Repeatability that doesn't get it. I think they read the two-page summaries of Deming, Juran and Crosby and missed the point. They should go back and read the entire book.
--heusser
>How did your thoughts evolve?
Now _that_ is an interesting question!
I spent seven years as a Civil Air Patrol Cadet while also reading the military science and science fiction success literature - especially Robert Heinlein.
You can learn a bit about that part of my life by checking out my amazon listmania lists:
https://www.amazon.com/gp/pdp/profile/A1MQIGB1G0X1ZA/103-6394374-2847053
During my time as a cadet, I mostly sought leadership ("command") positions; I desired power and position. We used to have these summer encampments where we "beat down" the first year cadets and then "built them back up in our image" - I never agreed with that model. Instead of summer encampment, the summer I was seventeen I went through real US Army Basic Training (In the Reserve), and realized there was a lot more too it than that. It's something between naive and just plain wrong to assume that a bunch of teenagers can do in a week what takes professional, trained drill sergeants do in two months.
Oh, and fear is a crappy motivator.
The following summer in staff training, I stood up and said "I think we're doing this wrong. Shouldn't our goal be to inspire cheerful and willing obedience to orders?"
Yes, it was a cliche, but that was good - half the room had heard the term before. The attitude of that encampment was split about 50/50, but I'm proud of what we did that year.
At 20 I became a professional programmer, and at 22 accepted a commission as an officer in the Civil Air Patrol. As an adult, my role changed from executive to advisor, coach, and mentor to cadets. About this time I realized that command was no test of leadership; people were expected to obey orders. Instead of seeking command positions where people had to listen to me, I sought staff positions where people had the option of ignoring me. That way, I had to develop my influence skills.
Professionally, I graduated with a Math degree and a concentration in Computer Science, not a CS degree, so I felt insecure about my skills, so I read every book I could find on development and methodology to "catch up." Eventually, I found that I knew more than the guy next to me, but I was still "Wrong" because I didn't get it; I kept going for this simple, elegant solutions instead of developing robust, reusable frameworks. I kept arguing for developing features in slices and saying that our crystal ball was wrong; every time we spent 6 months developing an extensible framework, the customer would request a new feature and we'd say "Gee, we never thought of that. THAT possibility isn't in our extensible framework ..."
Clearly, I didn't get it, so I went back to school at night and earned an MS in Computer Information Systems. About this time, I was studying Eli Goldratt, Alfhie Kohn, John P. Kotter, Michael Porter, Ed Yourdon, Steve McConnell, and Ron Jeffries. When I found extreme programming I about blew a gasket. :-)
Oh, I read Fred Taylor and Peter Drucker, and realized that the command and control structures in the typical North American company are based on an out-moded, anti-intellectual-for-workers approach that Taylor developed for European Immigrants in the early 1900's. The typical employee of his first study had, on average, a 3rd Grade Education - typically in German. Just like Drucker said, today's white collar worker is better educated and has a larger scope of responsibility than the 2nd-level supervisor of 1910.
After that, I started studying Jerry Weinberg and General Systems thinking. When I graduated, I found that I had developed a habit of spending ten hours a week on professional development, and just kept at it, turning that time into writing, speaking, and consulting.
Which takes us to today. I view software development as intellectually challenging, creative work. I am interested in two forms of innovation - upstream (ideas to improve the product) and downstream (ideas to change and improve the process.)
My curent bugabo is Traditional "process improvement" models that focus on creating stable, predictable, repeatable systems, or the focus on implementing a complete spec. My software projects are all different; trying to be repeatable when you are doing different things doesn't make sense to me. And the focus on the complete spec over collaboration eliminates my ability to do upstream innovation.
After fifteen years of feeling insecure about my skills and being patted on the head, told that one day I will "get it", I'm beginning to believe that it is in fact the Cult Of Repeatability that doesn't get it. I think they read the two-page summaries of Deming, Juran and Crosby and missed the point. They should go back and read the entire book.
--heusser
Subscribe to:
Posts (Atom)