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.
Tuesday, January 27, 2009
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.
Outliers - II
Later on in the book, Gladwell examines airplane crashes - and how they happen. Listen to this:
In a typical crash, for example, the weather is poor - not terrible, necessarily, but bad enough that the pilot feels a little more stressed than usual. In an overwhelming number of crashes, the plane is behind schedule, so the pilots are hurrying. In 52 percent of crashes, the pilot at the time of the accident has been awake for twelve hours or more, meaning that he is tired and not think thinking sharply. And 44 percent of the time, the two pilots have never flow together before, so they're not comfortable with each other. Then the errors start - and it's not just one error. The typical accident involves seven consecutive human errors. One of the pilots does something wrong that is not by itself a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to a catastrophe. But then we have a third error on top of that, and then another and another and another and another, and it is the combination of all these errors that lead to disaster.
Does any of that sound familiar? The project starts out in a negative climate - perhaps the stakeholders each have a different agenda. The project is late, so the technical team is hurrying. They aren't checking each other. They are working overtime, so they are tired. They begin to make mistakes - each, individually, won't kill the project, but when you add them up, they mean that when the code is delivered to test (or worse, to the customer), nothing works.
Now, in the past decade or so, a lot of shops have improved quality to the point that the story about is the exception - or even the stuff of legends. Hope springs eternal. Still, it gives a very strong strong argument for pair programming: After all, you wouldn't fly in a jet airplane without a co-pilot in the cockpit - why would you allow your business-critical applications to be developed without one?
More Gladwell:
These seven errors, furthermore, are rarely problems of knowledge or flying skil. It's not that the pilot has to negotiate some critical technical maneuver and fails. The kinds of errors that cause plane crashes are invariably errors of teamwork and communication. One pilot knows something important and somehow doesn't tell the other pilot. One pilot does something wrng, and the other pilot doesn't catch the error. A trick situation needs to be resolved through a complex series of steps - and somehow the pilots fail to coordinate or miss one of them.
We have the exact same problems in software development.
In my experience, on software projects, the problems are rarely technical. Instead, they are communications problems. The right people might know the right things, but fail to communicate it to the implementors, the architects, the testers, or the deployers. Somewhere in the mix, key elements get lost, forgotten, and lead to delivering software that doesn't meet customer needs, is buggy, late ... or possibly, all three.
Gladwell comes up with a few reasons that this happens; we'll talk about that tomorrow.
In a typical crash, for example, the weather is poor - not terrible, necessarily, but bad enough that the pilot feels a little more stressed than usual. In an overwhelming number of crashes, the plane is behind schedule, so the pilots are hurrying. In 52 percent of crashes, the pilot at the time of the accident has been awake for twelve hours or more, meaning that he is tired and not think thinking sharply. And 44 percent of the time, the two pilots have never flow together before, so they're not comfortable with each other. Then the errors start - and it's not just one error. The typical accident involves seven consecutive human errors. One of the pilots does something wrong that is not by itself a problem. Then one of them makes another error on top of that, which combined with the first error still does not amount to a catastrophe. But then we have a third error on top of that, and then another and another and another and another, and it is the combination of all these errors that lead to disaster.
Does any of that sound familiar? The project starts out in a negative climate - perhaps the stakeholders each have a different agenda. The project is late, so the technical team is hurrying. They aren't checking each other. They are working overtime, so they are tired. They begin to make mistakes - each, individually, won't kill the project, but when you add them up, they mean that when the code is delivered to test (or worse, to the customer), nothing works.
Now, in the past decade or so, a lot of shops have improved quality to the point that the story about is the exception - or even the stuff of legends. Hope springs eternal. Still, it gives a very strong strong argument for pair programming: After all, you wouldn't fly in a jet airplane without a co-pilot in the cockpit - why would you allow your business-critical applications to be developed without one?
More Gladwell:
These seven errors, furthermore, are rarely problems of knowledge or flying skil. It's not that the pilot has to negotiate some critical technical maneuver and fails. The kinds of errors that cause plane crashes are invariably errors of teamwork and communication. One pilot knows something important and somehow doesn't tell the other pilot. One pilot does something wrng, and the other pilot doesn't catch the error. A trick situation needs to be resolved through a complex series of steps - and somehow the pilots fail to coordinate or miss one of them.
We have the exact same problems in software development.
In my experience, on software projects, the problems are rarely technical. Instead, they are communications problems. The right people might know the right things, but fail to communicate it to the implementors, the architects, the testers, or the deployers. Somewhere in the mix, key elements get lost, forgotten, and lead to delivering software that doesn't meet customer needs, is buggy, late ... or possibly, all three.
Gladwell comes up with a few reasons that this happens; we'll talk about that tomorrow.
Monday, January 5, 2009
Outliers - I
When I think of Software Craftsmanship, I initially think of works like teach yourself programming in ten years or Richard Gabriel's Master's of Fine Arts In Software or perhaps Worse is Better.
But Craft applies to a lot more than software, and, every once in awhile, something totally outside of that realm with "smack me upside the head."
I'm reading Outliers: The Story of Success
by Malcolm Gladwell. I expected it to be great writing combined with interesting stories that didn't really apply to me - thankfully, I was right on the first count and wrong on the second.
About a third of way through the book, Gladwell begins writing about what makes work meaningful - and long it takes to generate skill in meaningful work. Here's an example:
"Those three things - autonomy, complexity, and a connection between effort and reward - are, most people agree, the three qualities that work has to do have if it is to be satisfying. It is not how much money we make that ultimately makes us happy between nine and five, it's whether our work fulfills us. It I offered you a choice between being an architect for $75,000 a year and working in a tollboth for $100,000 a year, which would you take? I'm guessing the former, because there is complexity, autonomy, and a relationship between effort and reward in doing creative work, and that's worth more to most of us than money."
Autonomy, Complexity, and a Connection Between Effort and Reward.
Autonomy, Complexity, and a Connection Between Effort and Reward.
That may not define software craftsmanship, but it's a good start.
But Craft applies to a lot more than software, and, every once in awhile, something totally outside of that realm with "smack me upside the head."
I'm reading Outliers: The Story of Success
by Malcolm Gladwell. I expected it to be great writing combined with interesting stories that didn't really apply to me - thankfully, I was right on the first count and wrong on the second.About a third of way through the book, Gladwell begins writing about what makes work meaningful - and long it takes to generate skill in meaningful work. Here's an example:
"Those three things - autonomy, complexity, and a connection between effort and reward - are, most people agree, the three qualities that work has to do have if it is to be satisfying. It is not how much money we make that ultimately makes us happy between nine and five, it's whether our work fulfills us. It I offered you a choice between being an architect for $75,000 a year and working in a tollboth for $100,000 a year, which would you take? I'm guessing the former, because there is complexity, autonomy, and a relationship between effort and reward in doing creative work, and that's worth more to most of us than money."
Autonomy, Complexity, and a Connection Between Effort and Reward.
Autonomy, Complexity, and a Connection Between Effort and Reward.
That may not define software craftsmanship, but it's a good start.
Welcome
Hello, folks. I've been developing, managing, or testing software products since 1997. In that, I've seen a number of principles, patterns, practices, fads, good ideas, bad ideas, and ideas that solved problem X (which you may or may not have) come and go.
Around 2001, in graduate school, I started a hand-rolled HTML website that became Excelon Development. WAIT - Don't Follow that link! It's yucky, hand-rolled HTML that I was doing part-time in Graduate School while developing full-time during the day. I didn't exactly put a ton of time into it!
After starting the XNDEV site, I did a blog that I hand-edited the HTML of - in VIM - on the UNIX command line. Yeah. You can still read it here. And, for awhile, I maintained a blog on use.perl.org.
Then, finally, in November of 2006, I started Creative Chaos - a blog that explores issues in software development with a systems thinking and testing slant - but my interests are not limited to stictly testing.
Lately, I've been interested in Technical Debt - this strange addiction cycle by which we feel pressue to hit a deadline, do a bad job, and set ourselves up for more pain next time we touch the code.
You can break the problem down into two parts: The ignorant, who don't know how to develop software well, and the talented but under pressure, who often fear for their jobs or personal safety - these people know better, but feel they have some excuse not to act. (A third category people generally bring up is "bad management" but I'm not sure I buy it. It is the technical person who makes the hack - not the manager. How can it be the manager's fault when that is not the person writing or testing the code?)
While I think the metaphor is helpful, I believe it expresses the problem - not the solution. One solution I find attractive is the idea of Software Craftsmanship. Craftsmanship provides training for the apprentice, which can solve the problem of ignorance, and a social system for the journeyman or master, which can solve the problem of pressure from the boss by counter-balancing it with pressure from a group of peers.
So I'm starting this blog, which will cover dynamics in software projects, lessons learned, agile development, upcoming projects, and so on. It will be a little more code-focused than Creative Chaos. Hopefully, this blog will allow audiences who are solely interested in one area or other the other to read without disappointment.
Ideally, of course, you are interested in both! :-)
Let's learn together.
Around 2001, in graduate school, I started a hand-rolled HTML website that became Excelon Development. WAIT - Don't Follow that link! It's yucky, hand-rolled HTML that I was doing part-time in Graduate School while developing full-time during the day. I didn't exactly put a ton of time into it!
After starting the XNDEV site, I did a blog that I hand-edited the HTML of - in VIM - on the UNIX command line. Yeah. You can still read it here. And, for awhile, I maintained a blog on use.perl.org.
Then, finally, in November of 2006, I started Creative Chaos - a blog that explores issues in software development with a systems thinking and testing slant - but my interests are not limited to stictly testing.
Lately, I've been interested in Technical Debt - this strange addiction cycle by which we feel pressue to hit a deadline, do a bad job, and set ourselves up for more pain next time we touch the code.
You can break the problem down into two parts: The ignorant, who don't know how to develop software well, and the talented but under pressure, who often fear for their jobs or personal safety - these people know better, but feel they have some excuse not to act. (A third category people generally bring up is "bad management" but I'm not sure I buy it. It is the technical person who makes the hack - not the manager. How can it be the manager's fault when that is not the person writing or testing the code?)
While I think the metaphor is helpful, I believe it expresses the problem - not the solution. One solution I find attractive is the idea of Software Craftsmanship. Craftsmanship provides training for the apprentice, which can solve the problem of ignorance, and a social system for the journeyman or master, which can solve the problem of pressure from the boss by counter-balancing it with pressure from a group of peers.
So I'm starting this blog, which will cover dynamics in software projects, lessons learned, agile development, upcoming projects, and so on. It will be a little more code-focused than Creative Chaos. Hopefully, this blog will allow audiences who are solely interested in one area or other the other to read without disappointment.
Ideally, of course, you are interested in both! :-)
Let's learn together.
Subscribe to:
Posts (Atom)
