While doing my Masters, we were given a project that was to be done in pairs. The aim was to use artificial intelligence (of sorts) to code a computer to act as a player in the game of Cluedo. The language of choice: Prolog. (I say choice in the loosest sense. It was foisted upon us.)
Myself and my good friend Jorge paired up and took the task very seriously. I learnt a huge amount about the strategy of Cluedo—it turned out that as a youngster, I had not used a jot of inference in playing the game, merely capturing in isolation each piece of information that had been given to me. (As a youngster, I was shit at Cluedo.) But once unleashed with this new-found knowledge, we came up with some kick-ass rules, one of which I was particularly proud of but which I couldn’t for the life in me remember some 15 years later.
We coded rule after rule, with multiple layers of logic deciphering any information provided to enhance the knowledge that had been gleaned to date; and yet more intricate logic determining which questions to ask, and who to ask them of.
But our program was shit. We came last as far as I remember. And here’s why.
The information aggregator worked like a dream. But each time it was our turn to ask a fellow player (which was itself a competitor team’s computer) a question, we always selected the same player to ask, and we always asked the same questions.
The reason: it was my fault. I’d come up with the beautiful, competitor-killing logic a couple of hours before the hard deadline, as I remember. We had a brief discussion over whether we had time to code it up. And we decided we would. The discussion probably went something like this:
Jorge: shall we implement it?
Dan: hell, yeah!
So we coded like the wind. And we got the code unit tested. And it kicked proverbial ass. And then, with moments to spare, we did some integration testing. And it borked the whole “asking” logic.
Now if we had any sense at all, we would have grabbed the floppy disk (oh yeah, baby!) containing the version of the program that we’d saved immediately before the killer module had been incorporated, handed it to the professor, and done pretty well in the competition. But in our haste (or speed, as the proverb oddly goes), we didn’t keep any such version. Instead, we had no option but to submit our borked version of the program and watch the result.
It was like watching the words of a particularly annoying parrot flash up on the screen, a parrot that had just been briefed on the basics of Waddingtons’ flagship product. Hell it was funny. (Jorge always helped make light of moments like that.) But at the same time it was so annoying: being so close to wiping the floor with our classmates (for that is what we would have done, natch), yet at the same time, being so far from that goal.
The big lesson I learnt from that experience was that deadlines are there for the client’s purposes, not your own. Define an end time or date for development, either in your head or on a plan, and stick to it. (Development here might mean coding, document production, analytics, basically any client deliverable.) And make sure that this milestone is sufficiently ahead of the formal deadline to allow for all of the necessary post-development activities—be they testing, document review or simply document formatting.
Your boss will often try to push the milestone to the right. In that event, push back strongly. And if this is futile, warn them strongly of the potential ramifications. For in this event 15 years ago, our (my) willingness to take on new requirements at such a time that didn’t allow for them to be fully tested compromised the entire project deliverable. Don’t let that happen to you.