{
I recently finished Moneyball, Michael Lewis's tale about general manager Billy Beane, the Oakland As, and the sport of professional baseball (note: I'm African and knew nothing about baseball for a long time - but after a few years playing fantasy online, I'm a major addict; it's hard to love math and hate baseball). What's special about the Oakland As is that as a small market team with nowhere near the financial resources of a team like the Yankees or the Red Sox, they do quite well in the major leagues - better than many of the money-rich competitors the play. What's special about Billy Beane is that he's been able to buoy the As performance by picking players that would have otherwise gone unnoticed for cents on the dollar.
Far be it from me to overextend the anecdotes of sport to something like software development but in this case I can't help thinking that a dominant culture of the development community online is obsessed with Fizz Buzz and functional programming languages in a manner similar to the way that old baseball scouts have an infatuation with high school standouts, good looks, and the Adonis body. I couldn't help but wonder about what was boring and yet obvious - the decisive factor between a good programmer and a bad one that was right under our noses but we miss because we're reading articles on the new shiny meme that is traversing the "blogosphere."
And then one thing came to mind... really a few weeks ago as I was reading Larry O'Brien's column in SD Times on estimation at a moment when my own lack of precision in the department had begun (and is still) eating at me. Estimation seems so pedestrian in comparison to Haskell, editors, language foibles, language pleasures, clever interview questions, and all the other things we look at for entertainment online. But I wonder if it isn't more important to be able to look at a project and give a relatively realistic guess at when you'll be finished - certainly in my case where the client is not going to notice my beautifully terse recursion inspired by Scheme under the covers, and they will become progressively discontented for each month that goes by when I'm still "working on things." I wonder that it isn't important enough for a guy like Atwood to call people unfit for programming over, or a major idea that sweeps across the net. Perhaps Agile methodologies fit into that, but more in the sense of philosophy than selection of team members and teammates.
What confirms this even more so is Steve McConnell's book on Software Estimation parked in the same spot it has been in our office over the last few years when we've rushed to everything (anything!) else: Fowler's Refactoring, C# References, Object Thinking, and the list goes on.
Estimation isn't exclusive to other traits that good programmers seem to have; in the same way that a person who happens to keep their On Base Percentage high doesn't necessarily do this at the expense of their Fielding capabilities. Indeed, a person who can reasonably estimate that a task will take them 50x longer than it would take others is probably in the wrong career to begin with, kind of like a baseball player who hits better than anyone else but is so phenomenally slow while making it around the bases.
Okay, that's all the sports and programming I have for a while...
}
I recently finished Moneyball, Michael Lewis's tale about general manager Billy Beane, the Oakland As, and the sport of professional baseball (note: I'm African and knew nothing about baseball for a long time - but after a few years playing fantasy online, I'm a major addict; it's hard to love math and hate baseball). What's special about the Oakland As is that as a small market team with nowhere near the financial resources of a team like the Yankees or the Red Sox, they do quite well in the major leagues - better than many of the money-rich competitors the play. What's special about Billy Beane is that he's been able to buoy the As performance by picking players that would have otherwise gone unnoticed for cents on the dollar.
Far be it from me to overextend the anecdotes of sport to something like software development but in this case I can't help thinking that a dominant culture of the development community online is obsessed with Fizz Buzz and functional programming languages in a manner similar to the way that old baseball scouts have an infatuation with high school standouts, good looks, and the Adonis body. I couldn't help but wonder about what was boring and yet obvious - the decisive factor between a good programmer and a bad one that was right under our noses but we miss because we're reading articles on the new shiny meme that is traversing the "blogosphere."
And then one thing came to mind... really a few weeks ago as I was reading Larry O'Brien's column in SD Times on estimation at a moment when my own lack of precision in the department had begun (and is still) eating at me. Estimation seems so pedestrian in comparison to Haskell, editors, language foibles, language pleasures, clever interview questions, and all the other things we look at for entertainment online. But I wonder if it isn't more important to be able to look at a project and give a relatively realistic guess at when you'll be finished - certainly in my case where the client is not going to notice my beautifully terse recursion inspired by Scheme under the covers, and they will become progressively discontented for each month that goes by when I'm still "working on things." I wonder that it isn't important enough for a guy like Atwood to call people unfit for programming over, or a major idea that sweeps across the net. Perhaps Agile methodologies fit into that, but more in the sense of philosophy than selection of team members and teammates.
What confirms this even more so is Steve McConnell's book on Software Estimation parked in the same spot it has been in our office over the last few years when we've rushed to everything (anything!) else: Fowler's Refactoring, C# References, Object Thinking, and the list goes on.
Estimation isn't exclusive to other traits that good programmers seem to have; in the same way that a person who happens to keep their On Base Percentage high doesn't necessarily do this at the expense of their Fielding capabilities. Indeed, a person who can reasonably estimate that a task will take them 50x longer than it would take others is probably in the wrong career to begin with, kind of like a baseball player who hits better than anyone else but is so phenomenally slow while making it around the bases.
Okay, that's all the sports and programming I have for a while...
}
Having said that, I try hard to make accurate estimates, and when I fail, I try to figure out what went wrong.