David Starr recently interviewed me for his podcast, "Elegant Code", and just put the interview up on the web today. The audio quality is a little choppy in parts, but I'm more interested in your feedback on the quality of the ideas.
You can download the MP3 directly here.
Monday, February 2, 2009
Tuesday, January 27, 2009
The Agile Aptitute Test
About two weeks ago, I sat in on a panel on Agile Development with Menlo Innovations co-founder Richard Sheridan; today Lisamarie Babik, Menlo's Cheif evangelist gave a talk on extreme interviewing at XPWestMichigan.
I couldn't make XPWM either, so I did the next best thing - I asked an editor at cio.com for permission to interview Lisamarie Babik and Richard Sheridan on the subject of the "Extreme Interview." The result is The Agile Aptitude test.
It's not quite a good as being there, but it's close, and, I have to say, a lot cheaper than a plane ticket to Grand Rapids.
I couldn't make XPWM either, so I did the next best thing - I asked an editor at cio.com for permission to interview Lisamarie Babik and Richard Sheridan on the subject of the "Extreme Interview." The result is The Agile Aptitude test.
It's not quite a good as being there, but it's close, and, I have to say, a lot cheaper than a plane ticket to Grand Rapids.
Wednesday, January 21, 2009
New Interview up
I just completed an interview with FreeLanceSwitch.com on my career and it's intersection with writing and public speaking. The interview is up here, and, as a Frequently Asked Questions list on guerilla marketing for the aspiring craftsperson, it ain't half bad.
I should say that I'm very happy with the interview as produced. At the same time, our discussion and the draft version had a little more ... humility in it. Yes, I stand in a pretty good position today, and yes, I could lose all of it tomorrow, and yes, when I speak, I try to keep that in mind.
I should say that I'm very happy with the interview as produced. At the same time, our discussion and the draft version had a little more ... humility in it. Yes, I stand in a pretty good position today, and yes, I could lose all of it tomorrow, and yes, when I speak, I try to keep that in mind.
Monday, January 12, 2009
The flip side of expertise
(I've got outliers bookmarked. I will come back to it, really. Now on to my post - I'm not sure where I'm going with this, and I've found that that type of expedition is often the most insightful. Please take this with a grain of salt ...)
Over the past few years, I have seen this pattern:
1) Developer writes moderately-complex system,
2) Over time, developer moves on
3) and a series of maintenance programmers touch the code,
4) The code changes, sometimes hacks, sometimes decent. These changes tend to each do one specific thing - and sometimes introduce unintended consequences and side-effects.
5) Time passes. 3 and 4 repeat. Eventually ...
6) The cumulative effect of these changes is technical debt; the code is brittle and expensive to change. Eventually, every change seems to introduce a problem at least as big as the change.
"How do you get out of the mess" is what a great deal of the tech debt literature suggests. Besides prevention, here are some of the options which haven't been explored very much:
1) Get acquired by another company that has the same type of system. Migrate to that system.
2) Declare bankruptcy. Stop supporting that business process, do things manually, etc. Sometimes, if this is the main line of the business, it involves actual bankruptcy.
3) Hire a genius. By this I actually mean someone with an IQ in the 140+ range. Sometimes, a "steward" who has stayed with the company for 5+ years and watched the system evolve can do this with an IQ in the 120-130 range.
I'm not sure how I feel abut option three. The problem with the genius programmer is that they really can track far more variables in their head at one time than the typical person - so they can continue to hack, stab, tear apart, and revise the brittle software and succeed at it.
A genius programmer can take a piece of software on it's last leg and keep it going for a few more years.
I suppose, if you are able to force the programmer to follow the Boy Scout Rule - to make each change over time make the code better - that could be a very good thing. Potentially, that programmer could pull the code out of the rabbit hole.
Next Question: If you are a programmer, should you aspire to be the genius?
Over the past few years, I have seen this pattern:
1) Developer writes moderately-complex system,
2) Over time, developer moves on
3) and a series of maintenance programmers touch the code,
4) The code changes, sometimes hacks, sometimes decent. These changes tend to each do one specific thing - and sometimes introduce unintended consequences and side-effects.
5) Time passes. 3 and 4 repeat. Eventually ...
6) The cumulative effect of these changes is technical debt; the code is brittle and expensive to change. Eventually, every change seems to introduce a problem at least as big as the change.
"How do you get out of the mess" is what a great deal of the tech debt literature suggests. Besides prevention, here are some of the options which haven't been explored very much:
1) Get acquired by another company that has the same type of system. Migrate to that system.
2) Declare bankruptcy. Stop supporting that business process, do things manually, etc. Sometimes, if this is the main line of the business, it involves actual bankruptcy.
3) Hire a genius. By this I actually mean someone with an IQ in the 140+ range. Sometimes, a "steward" who has stayed with the company for 5+ years and watched the system evolve can do this with an IQ in the 120-130 range.
I'm not sure how I feel abut option three. The problem with the genius programmer is that they really can track far more variables in their head at one time than the typical person - so they can continue to hack, stab, tear apart, and revise the brittle software and succeed at it.
A genius programmer can take a piece of software on it's last leg and keep it going for a few more years.
I suppose, if you are able to force the programmer to follow the Boy Scout Rule - to make each change over time make the code better - that could be a very good thing. Potentially, that programmer could pull the code out of the rabbit hole.
Next Question: If you are a programmer, should you aspire to be the genius?
Friday, January 9, 2009
This is how we do it ...
Our VP of Product, Adina Levin, presented how we develop software at Socialtext to the Silicon Valley Product Management Association yesterday. Details on my other blog, Creative Chaos, here.
Thursday, January 8, 2009
Wha the Bleep do we know?
My wife and I watched "What the Bleep do we know" Tuesday night. It was really interesting - a somewhat documentary with a story wrapped around it and a huge amount of special effects. Some of the conclusions were a little new-agey, but if you are a mature grown-up, I'm sure you can handle it.
Last night I watched the special features. Usually, I avoid them (the scenes that were cut were, it turns out, generally cut for a reason) - but I just wanted to hear more about the concepts.
One of the things that hit me was the budget. This was a movie originally budgeted at $250,000 as a documentary that ran to a total cost of $5 million.
That's two thousand percent over budget.
If it were a piece of software, according to the Chaos Report, it would be a failed project.
Yet wikipedia reads:
According to Publishers Weekly, the movie was one of the sleeper hits of 2004, as "word-of-mouth and strategic marketing kept it in theaters for an entire year." The article states that the gross exceeded $10 million, which is referred to as not bad for a low-budget documentary, and that the DVD release attained even more significant success with over a million units shipped in the first six months following its release in March 2005.
Keep in mind, 2005 was four years ago and only one year after theatrical release. Certainly, by now, the original investor has more than made his money back - mostly likely several multiples.
It's pretty hard to call that a "failure."
When we assess our failures in software development, it might be better if we looked at the overall outcome, instead of the initial budget.
Late projects don't mean the project failed - they mean that whoever did the up-front estimation probably failed at that singular task. Now, that is a bad thing, because the business made decisions based on unreasonable hope.
But it's not the only thing.
More Outliers to come.
(Hey, check it out, What the bleep is available for free on Google Video. I'd forgotten how cheesy the intro is. Man, you'll have to wade to at least the 5 minute point to get to the good stuff.)
Last night I watched the special features. Usually, I avoid them (the scenes that were cut were, it turns out, generally cut for a reason) - but I just wanted to hear more about the concepts.
One of the things that hit me was the budget. This was a movie originally budgeted at $250,000 as a documentary that ran to a total cost of $5 million.
That's two thousand percent over budget.
If it were a piece of software, according to the Chaos Report, it would be a failed project.
Yet wikipedia reads:
According to Publishers Weekly, the movie was one of the sleeper hits of 2004, as "word-of-mouth and strategic marketing kept it in theaters for an entire year." The article states that the gross exceeded $10 million, which is referred to as not bad for a low-budget documentary, and that the DVD release attained even more significant success with over a million units shipped in the first six months following its release in March 2005.
Keep in mind, 2005 was four years ago and only one year after theatrical release. Certainly, by now, the original investor has more than made his money back - mostly likely several multiples.
It's pretty hard to call that a "failure."
When we assess our failures in software development, it might be better if we looked at the overall outcome, instead of the initial budget.
Late projects don't mean the project failed - they mean that whoever did the up-front estimation probably failed at that singular task. Now, that is a bad thing, because the business made decisions based on unreasonable hope.
But it's not the only thing.
More Outliers to come.
(Hey, check it out, What the bleep is available for free on Google Video. I'd forgotten how cheesy the intro is. Man, you'll have to wade to at least the 5 minute point to get to the good stuff.)
Tuesday, January 6, 2009
How we gain expertise
Kathy Sierra did a 30-minute presentation at The O'Reilly Emerging Technology Conference on how we gain expertise - and the audio is available from ITConversations for free.
You canListen to it for free here.
You canListen to it for free here.
Subscribe to:
Posts (Atom)
