I made a posst to the Agile-Testing list a few months back about AgileCMMI; I thought it was worth repeating here:
>In the long run should we have 'agile CMM'?
Ok. I'm going to take a stand here.
The Agile Manifesto has an explicit value system - individuals and interactions over processes and tools, customer collaboration over contract negotiation, and so on. In fact, from the research I've done, the Agile Manifesto was very much a reaction to the heavyweight processes of the 1980's and 1990's - often symbolized by the very term 'CMM'
And, in this corner, weighing in at 711 pages, is the CMMI for Systems Engineering, Software Engineering, Integrated Product and Process Development, and so on.
The CMMI itself -implies- a value system involving comprehensive documentation, processes and tools, and contract negotiation. I would gladly debate, point-for-point, the existence of this value system - but for purposes of this email, let's just assume that, like Prego, "It's in there."
So, on first blush, Agile CMMI seems to make no sense at all. It's silly. It's like a peanut-butter and fish sandwich - why would you want that?
However, a second look shows something interesting.
Say the organization is a DoD Supplier, Forced to do the CMMI thing. Taking an 'Agile' Edge to it means asking questions like this:
- "We have to do comprehensive documentation. What does 'comprehensive' really mean? What is the minimum amount of documentation needed, and how much can we shift our focus toward working software?"
- "We have to have defined processes and tools. How can we define our processes to be as flexible as possible, so that they enable the greatest freedom to individuals to make good decisions in the moment, based on sound judgement?"
- "We have to have a defined contract negotiated up front. How can we write a contract to enable change and collaboration?"
If you *have* to do CMMI, these might be good questions to ask. In other words, while I might view Agile CMMI as a compromise, it beats the heck out of surrender. :-)
Friday, December 15, 2006
Shark Jumpin' - II
Ben Edwards commented yesterday that in TV Shows, the characters age and the writers need to introduce new characters or plotlines to keep things interesting. Those things may make the show jump the Shark, argues Ben, but Agile has "just been around for a while and is gaining followers ad people, tired of the old ways of doing things, are looking for something that works better."
There's nothing wrong with that, and I applaud it, but I'd like to take a few moments to talk about the system effects of a mass movement.
First of all, it's now much less of a career risk to pursue agile development. Lots of companies are doing it, and "Agile RUP" or "Agile CMMI" is far less threatening than Extreme Programming. Automated Unit Tests, TDD, and xUnit frameworks are hitting the early mainstream, and vendors are adding refactoring tools to IDE's like Visual Studio.
Second, the original Agile movement was a re-action to the heavyweight, documentation-centric processes and methods of the 1980's and 1990's. More than a few people noticed that it's really hard to move a heavy boat, and that extra documentation adds mass. They also noticed that the "Crystal Ball" of a project beyond 90 days doesn't work. So a bunch of guys got together at the snowbird conference and suggested lean artifacts, planning in short increments, and adjustment.
There are several problems that the agile manifesto just plain punts on: For example, the idea that you can be on-time, on-budget, high-quality, feature complete. Forget about it - at the beginning of a large project, the customer doesn't even know what features he wants - who are we kidding?
But ... there's a problem. Lots of companies want to be able to predict all that stuff, to the point that it is better to be certain and wrong than to be uncertain. I have experienced this first-hand, and DeMarco and Lister comment on this in "Waltzing With Bears." Another Example: Extreme Programming doesn't have a concept of "architecture" or a role of Architect. It simply doesn't address the whole, er, problem space, that, um ... Enterprisy-Architecty-Modelling-y things address. (Whatever)
By "punting" on problems that it can't solve, the agile manifesto makes it possible to deliver great software regularly with considerably less waste.
The problem is that by saying "Embrace Change", we are also saying "Get over your fear of loss of control", and there are a whole lot of people in this world who don't want to. They want to be told that they can have their pie and eat it too. And they have titles like VP of Development, CIO, CEO, or CTO.
This means there is a market, with money, who want to be told how they can have all this agile stuff and also have CMMI, or Architecture, or Portfolio Management, Long Range Planning, or a Crystal Ball.
In fact, one of the consistent things I hear on software discussion lists is "We want to be agile but how do we solve problem X." Where problem X is something that is addressed by one of the technologies above.
For the first couple of years, the answers I saw on the lists were consistenly something like "Gee, we've been doing agile for two years and never had a problem with issue tracking. We talk about it at the standup, and we fix it." Eventually, though, I started to see answers more like this:
"Yes, my company thought of the same problem before we switched to Agile, so we use AgileBugTracker, by SuperAgileSoftware. It's great!"
It shouldn't be surprise; Adam Smith tells us that someone will start a business to exploit that opportunity.
So we get Agile RUP and Agile CMMI and Agile Portfolio Management, Agile Issue Tracking and Resolution, Agile Systems Architecture, and get slowly pulled back into the world we were trying to escape from.
The tent is too big and we've given credence to ideas and concepts that we should not have, to the point that it is very hard to tell "good Agile" from a bunch of consultants that can't ship software but know the right buzzwords.
Personally, I am a member of the American Society for Quality, and I have read Crosby, Drucker, Juran, and Deming: I went through the 600-page books and know the difference between "Getting It" and using the buzzwords. And I have real concern that Agile is in danger of becoming TQM or Six Sigma: Inherently good but misunderstood more often than not. That is what I mean by jumping the shark.
Next time: Agile CMMI, Jim Brosseau's comments, and more ...
There's nothing wrong with that, and I applaud it, but I'd like to take a few moments to talk about the system effects of a mass movement.
First of all, it's now much less of a career risk to pursue agile development. Lots of companies are doing it, and "Agile RUP" or "Agile CMMI" is far less threatening than Extreme Programming. Automated Unit Tests, TDD, and xUnit frameworks are hitting the early mainstream, and vendors are adding refactoring tools to IDE's like Visual Studio.
Second, the original Agile movement was a re-action to the heavyweight, documentation-centric processes and methods of the 1980's and 1990's. More than a few people noticed that it's really hard to move a heavy boat, and that extra documentation adds mass. They also noticed that the "Crystal Ball" of a project beyond 90 days doesn't work. So a bunch of guys got together at the snowbird conference and suggested lean artifacts, planning in short increments, and adjustment.
There are several problems that the agile manifesto just plain punts on: For example, the idea that you can be on-time, on-budget, high-quality, feature complete. Forget about it - at the beginning of a large project, the customer doesn't even know what features he wants - who are we kidding?
But ... there's a problem. Lots of companies want to be able to predict all that stuff, to the point that it is better to be certain and wrong than to be uncertain. I have experienced this first-hand, and DeMarco and Lister comment on this in "Waltzing With Bears." Another Example: Extreme Programming doesn't have a concept of "architecture" or a role of Architect. It simply doesn't address the whole, er, problem space, that, um ... Enterprisy-Architecty-Modelling-y things address. (Whatever)
By "punting" on problems that it can't solve, the agile manifesto makes it possible to deliver great software regularly with considerably less waste.
The problem is that by saying "Embrace Change", we are also saying "Get over your fear of loss of control", and there are a whole lot of people in this world who don't want to. They want to be told that they can have their pie and eat it too. And they have titles like VP of Development, CIO, CEO, or CTO.
This means there is a market, with money, who want to be told how they can have all this agile stuff and also have CMMI, or Architecture, or Portfolio Management, Long Range Planning, or a Crystal Ball.
In fact, one of the consistent things I hear on software discussion lists is "We want to be agile but how do we solve problem X." Where problem X is something that is addressed by one of the technologies above.
For the first couple of years, the answers I saw on the lists were consistenly something like "Gee, we've been doing agile for two years and never had a problem with issue tracking. We talk about it at the standup, and we fix it." Eventually, though, I started to see answers more like this:
"Yes, my company thought of the same problem before we switched to Agile, so we use AgileBugTracker, by SuperAgileSoftware. It's great!"
It shouldn't be surprise; Adam Smith tells us that someone will start a business to exploit that opportunity.
So we get Agile RUP and Agile CMMI and Agile Portfolio Management, Agile Issue Tracking and Resolution, Agile Systems Architecture, and get slowly pulled back into the world we were trying to escape from.
The tent is too big and we've given credence to ideas and concepts that we should not have, to the point that it is very hard to tell "good Agile" from a bunch of consultants that can't ship software but know the right buzzwords.
Personally, I am a member of the American Society for Quality, and I have read Crosby, Drucker, Juran, and Deming: I went through the 600-page books and know the difference between "Getting It" and using the buzzwords. And I have real concern that Agile is in danger of becoming TQM or Six Sigma: Inherently good but misunderstood more often than not. That is what I mean by jumping the shark.
Next time: Agile CMMI, Jim Brosseau's comments, and more ...
Thursday, December 14, 2006
Agile Jumped the Shark? - I
On Happy Days, there was an episode where Fonzie jumped a shark tank on his motorcycle. Many people consider that the "high water" mark of the show, and believed that once the show reached that pinnacle, it had no where to go but down. There is even a website, JumpTheShark.com, devoted to chronicalling when TV shows start to go downhill.
That said, I'd like to share a few facts:
- Agile was originally a cosortium of a bunch of like-minded groups: Scrum, DSDM, Crystal, and Extreme Programming. The goal was to make a bigger tent.
- The tent is getting bigger each year. You can now google for "Agile RUP" or "Agile CMMI" and get a considerable number of results. The agile conference grew to 1,100 people last year and I believe is predicted at 1,500 this year. Instead of a band of rebels, it's now 'hip' to be agile. (That means it will attract an entirely different group of people than it did four years ago, when the only people who knew what agile were active readers of the wikiwikiweb.)
- Jon Kohl and I have been concerned about the state of the agile world for about a year now.
- Yesterday, Elisabeth Hendrickson posted Inside the Secret Fears of Agilists, which stated as a top concern that the big global outsourcing companies would adopt Agile as a buzzword, just like Service-Oriented, Business Intelligence, Global Sourcing, and 'Enterprise'
- My friends who are certified scrum masters are now using the term "use what works" to justify studying for the PMP exam
- Yesterday, my collegue Paul, the web manager, threw his copy of XP 1st Edition into the trash can, telling me "We're doing back to BUFD" (Big Up-Front Design)
There are a lot of reasons this is happening, and I would like to discuss it, but first I'd like to say that I think Jon and Elisabeth are spot-on. Go read them.
As for me, more to come later.
That said, I'd like to share a few facts:
- Agile was originally a cosortium of a bunch of like-minded groups: Scrum, DSDM, Crystal, and Extreme Programming. The goal was to make a bigger tent.
- The tent is getting bigger each year. You can now google for "Agile RUP" or "Agile CMMI" and get a considerable number of results. The agile conference grew to 1,100 people last year and I believe is predicted at 1,500 this year. Instead of a band of rebels, it's now 'hip' to be agile. (That means it will attract an entirely different group of people than it did four years ago, when the only people who knew what agile were active readers of the wikiwikiweb.)
- Jon Kohl and I have been concerned about the state of the agile world for about a year now.
- Yesterday, Elisabeth Hendrickson posted Inside the Secret Fears of Agilists, which stated as a top concern that the big global outsourcing companies would adopt Agile as a buzzword, just like Service-Oriented, Business Intelligence, Global Sourcing, and 'Enterprise'
- My friends who are certified scrum masters are now using the term "use what works" to justify studying for the PMP exam
- Yesterday, my collegue Paul, the web manager, threw his copy of XP 1st Edition into the trash can, telling me "We're doing back to BUFD" (Big Up-Front Design)
There are a lot of reasons this is happening, and I would like to discuss it, but first I'd like to say that I think Jon and Elisabeth are spot-on. Go read them.
As for me, more to come later.
Wednesday, December 13, 2006
If you hate it, do more of it
I was talking to Tessa yesterday about the PMP certification, which I am not exactly a big fan of. She reminded me of the old adage 'if you hate it, do more of it.'
In other words, if you have windows, learn dotNet. If you hate this Ruby/RailsNation thing, give it a try. If testing is annoying to you, invest some time in growing your skill. Not only will those things become less painful and less annoying, but you may pick up a few interesting, new, and different ideas to take back to your world of Linux, Perl, or Development. It is even possible (not probable, but possible) that you learn to see what you hate in an entirely different light, and, if not like it, at least appreciate it's strengths.
Tessa's right. After all, that's how I became a CMM(I) expert. I still find the CMMI in bad taste, but I'm an expert. :-)
Now, I've allready invested a good bit of time in learning about the world of the Project Management Institute, but I am resolved to give it another look.
More importantly, though, I just got off of a treadmill, followed by a resistance workout.
I hate it. I resolve to do more of it. :-)
In other words, if you have windows, learn dotNet. If you hate this Ruby/RailsNation thing, give it a try. If testing is annoying to you, invest some time in growing your skill. Not only will those things become less painful and less annoying, but you may pick up a few interesting, new, and different ideas to take back to your world of Linux, Perl, or Development. It is even possible (not probable, but possible) that you learn to see what you hate in an entirely different light, and, if not like it, at least appreciate it's strengths.
Tessa's right. After all, that's how I became a CMM(I) expert. I still find the CMMI in bad taste, but I'm an expert. :-)
Now, I've allready invested a good bit of time in learning about the world of the Project Management Institute, but I am resolved to give it another look.
More importantly, though, I just got off of a treadmill, followed by a resistance workout.
I hate it. I resolve to do more of it. :-)
Interesting Links
Scott Ambler has an article in this months Dr. Dobbs Magazine on Agile Testing:
http://www.ddj.com/dept/debug/196603549
Yesterday, Sean McMillan sent me this link to Big Agile Up Front:
http://c2.com/cgi/wiki?BigAgileUpFront
I'm beginning to see a theme here, a theme that I have also seen in the real world. People want things to be "all figured out"; to have the best way of doing something.
It reminds me of that old saw that a camel is a horse designed by committee.
No thank you. Give me conscious design tradeoffs any day.
http://www.ddj.com/dept/debug/196603549
Yesterday, Sean McMillan sent me this link to Big Agile Up Front:
http://c2.com/cgi/wiki?BigAgileUpFront
I'm beginning to see a theme here, a theme that I have also seen in the real world. People want things to be "all figured out"; to have the best way of doing something.
It reminds me of that old saw that a camel is a horse designed by committee.
No thank you. Give me conscious design tradeoffs any day.
Tuesday, December 12, 2006
Coding Standards ?
This month's Software Quality Professional claims on page 51 that:
By having defined coding standards, developers trained in the use of the those standards are less likely to make certain coding errors.
The one thing coding standards guarentee is consistency, and, arguably, readability. But less errors? I grant that in theory, coding standards can prevent errors. For example, "Don't use global variables", "Every function should have an automated test" or "In perl, use auto-indexing in for loops instead of C-style ++" - something like that can decrease errors.
Then again, those are often best learned through mentoring and good craftsmanship, not code standards. Most of the code standards I have seen obsess over where to place the curly braces, what to name the variables, and how many spaces to indent.
In fact, I have seen so-called fagan-style reviews that focused entirely on that kind of slavish adherance to standard; hours spent without a single defect found that would actually impact a customer.
This is couched inside an editorial, not a journal paper, so I give the author a little wiggle room, but here's my suggestion: If you want to make a statement like this in a professional journal, either provide a lot of supporting evidence, or be honest. "In my experience" is a great way to be honest; failing that, give at least one tangible example. Otherwise, we run the risk of coming off disconnected and enterprisy.
Is that too much to ask?
By having defined coding standards, developers trained in the use of the those standards are less likely to make certain coding errors.
The one thing coding standards guarentee is consistency, and, arguably, readability. But less errors? I grant that in theory, coding standards can prevent errors. For example, "Don't use global variables", "Every function should have an automated test" or "In perl, use auto-indexing in for loops instead of C-style ++" - something like that can decrease errors.
Then again, those are often best learned through mentoring and good craftsmanship, not code standards. Most of the code standards I have seen obsess over where to place the curly braces, what to name the variables, and how many spaces to indent.
In fact, I have seen so-called fagan-style reviews that focused entirely on that kind of slavish adherance to standard; hours spent without a single defect found that would actually impact a customer.
This is couched inside an editorial, not a journal paper, so I give the author a little wiggle room, but here's my suggestion: If you want to make a statement like this in a professional journal, either provide a lot of supporting evidence, or be honest. "In my experience" is a great way to be honest; failing that, give at least one tangible example. Otherwise, we run the risk of coming off disconnected and enterprisy.
Is that too much to ask?
A Few Of My Favorite Things - IV
I am vaguely disorganized.
No, please don't jump out of your seat and tell me that I "Have" to get more organized.
I don't buy it. I've run a successful regional software conference with my methods; they seem to be doing just fine.
I used to tell a story about how I felt bad or guilty for being so disorganized, until I saw David Parker's Office at Salisbury University. Dr. Parker was is one of the best problem solvers I have ever met, and he had literally two feet of paper covering his entire office. He was promoted to Department Chair the year after I met him.
Yet many of the organization folks still don't buy it. That was an exception; being "Organized" is "right."
Ok, I'll try again. One more time: My creative output is an order of magnitude higher than any 'organization evangelist' that I have ever met. When I read storys of Euler, Guass, Einstein, Joedel, Escher, Newton ... they sound a lot more like me than the organization people.
Personally, I value the Creative Chaos. Heck, it's the name of my blog.
At the same time, I recognize the consequences of that kind of thought-life style. Things do get missed. Things do get forgotten. When I get an idea in my head (a hundred years ago, they would say "when the muse strikes") I zone out of the real world until I can get the idea down, or, worse, I lose the idea.
Ugh.
So here's the tool of the day: 3x5 Index Cards.
I use index cards for everything.
Blog ideas
Testing ideas
Managing evolving requirements
Moving from a vague and floofy requirement to something concrete
Getting those concrete requirements in some sort of priority
Article ideas
Presentation ideas
Bullets points
Things to come back to
Groceries to pick up on the way home
Things to not forget
No, they aren't organized. My 'system' consists of the blank cards, a wallet-like holder, and a place to stick finished cards. I also have a box for requirements cards.
There are piles of index cards all over, and things still get lost, but less things get lost, and I can swap ideas out of my head with less fear of losing them.
For me, index cards aren't an organization strategy; they are a way to compensate for my lack of organization.
My next step will probably be to get a notebook, so there is a sense of order and history to the notes; this might help me recollect ideas later. The problem is that the notebook will have to be about the size of a PDA, or I won't carry it with me ...
Still, today's favorite tool is a 3x5 index cards. If you want one single ridiculously cheap tool to start trying today, there's my number one suggestion.
No, please don't jump out of your seat and tell me that I "Have" to get more organized.
I don't buy it. I've run a successful regional software conference with my methods; they seem to be doing just fine.
I used to tell a story about how I felt bad or guilty for being so disorganized, until I saw David Parker's Office at Salisbury University. Dr. Parker was is one of the best problem solvers I have ever met, and he had literally two feet of paper covering his entire office. He was promoted to Department Chair the year after I met him.
Yet many of the organization folks still don't buy it. That was an exception; being "Organized" is "right."
Ok, I'll try again. One more time: My creative output is an order of magnitude higher than any 'organization evangelist' that I have ever met. When I read storys of Euler, Guass, Einstein, Joedel, Escher, Newton ... they sound a lot more like me than the organization people.
Personally, I value the Creative Chaos. Heck, it's the name of my blog.
At the same time, I recognize the consequences of that kind of thought-life style. Things do get missed. Things do get forgotten. When I get an idea in my head (a hundred years ago, they would say "when the muse strikes") I zone out of the real world until I can get the idea down, or, worse, I lose the idea.
Ugh.
So here's the tool of the day: 3x5 Index Cards.
I use index cards for everything.
Blog ideas
Testing ideas
Managing evolving requirements
Moving from a vague and floofy requirement to something concrete
Getting those concrete requirements in some sort of priority
Article ideas
Presentation ideas
Bullets points
Things to come back to
Groceries to pick up on the way home
Things to not forget
No, they aren't organized. My 'system' consists of the blank cards, a wallet-like holder, and a place to stick finished cards. I also have a box for requirements cards.
There are piles of index cards all over, and things still get lost, but less things get lost, and I can swap ideas out of my head with less fear of losing them.
For me, index cards aren't an organization strategy; they are a way to compensate for my lack of organization.
My next step will probably be to get a notebook, so there is a sense of order and history to the notes; this might help me recollect ideas later. The problem is that the notebook will have to be about the size of a PDA, or I won't carry it with me ...
Still, today's favorite tool is a 3x5 index cards. If you want one single ridiculously cheap tool to start trying today, there's my number one suggestion.
Monday, December 11, 2006
Interview with Chad Fowler
I've blogged a bit about a presentation Chad Fowler made to XPWestMichiga two weeks back. There were several interesting points on marketing yourself and choosing a career in technology. Eventually, the talk will be on Google video and I'll link to it, but I am getting tired of waiting to post something.
In the mean time, there is an interview with Chad on perlcast.com which covers some of the main points; you can download it here.
In the mean time, there is an interview with Chad on perlcast.com which covers some of the main points; you can download it here.
Christmas Tree Shoppin' ...
Imagine: You bundle up the kids and drive ten miles to the Christmas tree farm. Before you can park your car, a young man greets you, asking you to roll down your windows. He asks if you have been to this farm before, you reply "No."
Giving you a wide grin, the young man says "Welcome to Wahmhoff tree farm. We have pre-cut trees right here, but you can also cut your own. Yes, cutting your own is a few dollars cheaper. Did you bring a saw? No problem, we have them on loan in the gift shop for deposit. We have five varieties, with examples over there; prices are on the back of the brochure. The tractor can show you around the farm, drop you off and pick you up. Or, you could walk out; we've got free hand carts on loan. Or you could drive your mini-van right up to the tree you want. We also have free horse-drawn carriage rides today; you could load up your tree on that if you'd like, or just ride around the farm with the kids.
There is free warm popcorn in the gift shop, free pictures with Santa, and a free coloring book for the kids. Is there anything I can help you with?"
Wahmhoff farms is a real place in Gobles, Michigan. When you purchase the tree, they have a machine that shakes out all the dead needles, then they can drill a hole in the bottom for free. (They also sell a special stand with a big peg in the middle.) For a dollar, they have a baling machine that essentially surrounds your tree in shrink-wrap.
Why am I telling you about Wahmoff farms? Well, think about the business model. A nice tree is a nice tree is a nice tree, but they are able to create competitive advantage anyway. They do it by giving stuff away. There was so much to do that we drive ten miles out of our way to make an aftertoon of it, and we'd gladly do it again.
When it got time for me to hand over my forty-five bucks (and it was forty-five because of the stand), I hardly even noticed I was paying, because it was surrounded by so much free. Yet the stand created lock-in; next year, we'll think "We'd better go to Gobles, or else get out the drill ..." or "Better not buy a fake tree, because we invested in that expensive tree stand ..."
In the era of $79.95 looks-just-like real Christmas trees at Target, and heavy competition among real tree farms, Wahmhoff is doing something right, and the market is rewarding them for it.
Whymoff farms doesn't have customers. They have fans. This is a different business model for technologists, and it's one that I think is worth exploring.
Oh, By the way - the saw was wicked Sharp. They must sharpen them at least ever week ...
Giving you a wide grin, the young man says "Welcome to Wahmhoff tree farm. We have pre-cut trees right here, but you can also cut your own. Yes, cutting your own is a few dollars cheaper. Did you bring a saw? No problem, we have them on loan in the gift shop for deposit. We have five varieties, with examples over there; prices are on the back of the brochure. The tractor can show you around the farm, drop you off and pick you up. Or, you could walk out; we've got free hand carts on loan. Or you could drive your mini-van right up to the tree you want. We also have free horse-drawn carriage rides today; you could load up your tree on that if you'd like, or just ride around the farm with the kids.
There is free warm popcorn in the gift shop, free pictures with Santa, and a free coloring book for the kids. Is there anything I can help you with?"
Wahmhoff farms is a real place in Gobles, Michigan. When you purchase the tree, they have a machine that shakes out all the dead needles, then they can drill a hole in the bottom for free. (They also sell a special stand with a big peg in the middle.) For a dollar, they have a baling machine that essentially surrounds your tree in shrink-wrap.
Why am I telling you about Wahmoff farms? Well, think about the business model. A nice tree is a nice tree is a nice tree, but they are able to create competitive advantage anyway. They do it by giving stuff away. There was so much to do that we drive ten miles out of our way to make an aftertoon of it, and we'd gladly do it again.
When it got time for me to hand over my forty-five bucks (and it was forty-five because of the stand), I hardly even noticed I was paying, because it was surrounded by so much free. Yet the stand created lock-in; next year, we'll think "We'd better go to Gobles, or else get out the drill ..." or "Better not buy a fake tree, because we invested in that expensive tree stand ..."
In the era of $79.95 looks-just-like real Christmas trees at Target, and heavy competition among real tree farms, Wahmhoff is doing something right, and the market is rewarding them for it.
Whymoff farms doesn't have customers. They have fans. This is a different business model for technologists, and it's one that I think is worth exploring.
Oh, By the way - the saw was wicked Sharp. They must sharpen them at least ever week ...
Scaling Knowledge work ...
Ron Jeffries has an interesting article on a project he is currently working on.
I read the article and responded to the XP E-mail list; here's a copy of the response.
Ron Jeffries Wrote:
I wonder what would happen if Chet and I were putting in four or eight hours a day on this thing. Suppose we're averaging two now, and we did eight. Would we go four times faster in elapsed time to a given feature?
This is a real problem in the freelance writing world as well. People think "Gee, I can knock out a story on a Saturday, I could knock out five a week ... I can afford to go full time!" and it doesn't work out that way.
Besides the obvious marketing and sales problem when you 5x your output, it turns out that nearly all humans have creative output go down when they try to do a lot of it at a sustained pace.
It might be possible to spend 40 hours a week programming CRUD database-backed web forms, but innovating, you find yourself doing ... other stuff. And sometimes, you're just plain blocked. (Zen and the Art of Motorcycle Maintenance is a good reference; Wicked Problems, Righteous Solutions describes this anecdotally as well.)
I think pair programming helps with that because if one person is blocked, the second can "bring them along", and the time spent not programming is probably going to be used to something more valuable than surfing the web.
The freelance world knows this (pick up any book on the business of writing), but in the software world we are just starting to realize that IP work doesn't scale linearly.
Then again, there's always those guys like Issac Asimov that could just sit
at a typewriting and type for days. But, I suppose that's a different post, and for every one of those, there are a thousand Arthur C. Clarke's ...
I read the article and responded to the XP E-mail list; here's a copy of the response.
Ron Jeffries Wrote:
I wonder what would happen if Chet and I were putting in four or eight hours a day on this thing. Suppose we're averaging two now, and we did eight. Would we go four times faster in elapsed time to a given feature?
This is a real problem in the freelance writing world as well. People think "Gee, I can knock out a story on a Saturday, I could knock out five a week ... I can afford to go full time!" and it doesn't work out that way.
Besides the obvious marketing and sales problem when you 5x your output, it turns out that nearly all humans have creative output go down when they try to do a lot of it at a sustained pace.
It might be possible to spend 40 hours a week programming CRUD database-backed web forms, but innovating, you find yourself doing ... other stuff. And sometimes, you're just plain blocked. (Zen and the Art of Motorcycle Maintenance is a good reference; Wicked Problems, Righteous Solutions describes this anecdotally as well.)
I think pair programming helps with that because if one person is blocked, the second can "bring them along", and the time spent not programming is probably going to be used to something more valuable than surfing the web.
The freelance world knows this (pick up any book on the business of writing), but in the software world we are just starting to realize that IP work doesn't scale linearly.
Then again, there's always those guys like Issac Asimov that could just sit
at a typewriting and type for days. But, I suppose that's a different post, and for every one of those, there are a thousand Arthur C. Clarke's ...
Subscribe to:
Posts (Atom)