Well, we can chalk up my month-long hiatus from posting to that blackest of software arts, time estimation. In the understatement of the century, Wikipedia notes:
The ability to accurately estimate the time/cost taken for a project to come in to its successful conclusion is a serious problem for software engineers.
In order to deal with this problem, I've tried everything from function point analysis to tasseography...
...and although this won't be a popular statement, let me tell you what I think: none of it really works.
Not really.
No matter how careful we are, and regardless of what statistical methods we apply, we'll find that software suffers from a sort of Heisenberg Uncertainty principle. It's almost impossible to observe a piece of software or to accurately predict how long it will take it to travel a certain distance on the development timeline. The best we can do is get a ballpark figure, and rely on the fact that our programmers will make a valiant effort to manhandle the project workload into the project schedule.
The problem here is one of loose wiring, a term I first came across reading Caro's Book of Poker Tells
You see, your poker opponents are volatile beings. They can be impressionable, irritable, playful, capricious, and more. You don't know when they're going to short out, cross-circuit, or doing the silliest or the most brilliant things. This goes for all poker players, from the weakest beginners to the most seasoned pros. The deal is that even when opponents are playing a disciplined game of poker, so many of their decisions are borderlined that what they're going to do is anybody's guess
The idea is that given the exact same player, the exact same opponents, the exact same set of cards, the same amount of money, player actions will vary wildly just based on the current price of garbage in Moscow, or an increase in the butterfly population of Madrid. There's no telling what people will actually do, even if you present them with identical situations. Instead we have to contend with built-in unpredictability, a sort of inherent randomness to the world.
This is true not only in poker, but in life, and especially in programming.
The same programmer, given the same exact workload, given the same circumstances, will take anywhere between 50% to 150% as long to finish his work, based on nothing at all. Mood. Whim. Luck. The bad Chicken Marsala he ate last night. There's no way to predict this, no way to quantify it. The best you can do is resort to statistical methods to try to tame the beast. And even those don't work as well as we'd like, because the numbers we build are like houses of cards, prone to tumbling as soon as the assumptions that allowed us to generate those numbers are proven to be hopelessly naive, or on the other end of the spectrum, ridiculously conservative.
So for all these reasons and more, I've been hammered for the past three weeks playing catch-up on a side project, and unable to post. Cue the violins.
That project is finally concluded and for those of you who've asked whether the botting series will continue, the answer is absolutely. I hope you'll stay tuned as we continue discussing the mechanical aspects of poker botting, and as we start looking at the poker strategy and A.I. side of things more closely. We'll also touch on some other topics that I think you'll find quite interesting, if not shocking.
Expect the next post within 24 hours, give or take.
(But as I say that it occurs to me that estimating future publication dates is a bit of a black art, too, and even more difficult, in its own way, than estimating software completion times.)
Luckily this content is already written.
(But as I say that it occurs to me that content, like software, is never really complete. It can always be improved, honed, refactored.)
In the words of a poet:
What a tangled web of unrealistic schedules and intractable time-based dependencies we create, when first we start to estimate...
So, expect the next post within 12 to 36 hours, by the 50/150 rule stated above, and in the meantime: have you ever come across a software time-estimation method that actually works?
How good (or bad) are your software estimation skills?
Are they as bad as mine? As in need of constant oversight and refactoring? Or are you that rarest of creatures, the Bigfoot of Software Engineering...
A time estimation virtuoso?
Posted by James Devlin 31 comment(s)
Subscribe via RSS
Subscribe via email
