Tip of the Iceberg

Category philosophy
During my vacation last week, I spent a surprising amount of time pondering what I've now taken to calling "expiring plausibility". As an idealist, I'd like to believe that anything's possible; as a pragmatist I know that's not true: any given possibility is finitely plausible until the arrow of time simplifies the likelihood of its occurrence to a mere Boolean result. This is a mixed blessing: the abstract concepts of regret and gratitude (among others) are entirely dependent upon expiring plausibility. Time, therefore, is the key ingredient; although various branches of theoretical physics are calling into question our one-directional experience of time, the deterministic nature of that experience is the very phenomenon that allows plausibility to expire.

Generically, this is more often referred to as "probability", and there are many ways to measure and express it, such as Bayes' theorem (which is the basis for the Bayesian probability approach to spam and phish filtering - that is, scanning message content to determine the probability of it being unwanted). But I came up with my own simplistic equation, which is highly influenced by my typically dual role of project manager and software developer:

P = (R / O) * T

In English, the plausibility of a pending outcome at any moment is equal to the ratio of available resources to obstacles, multiplied by the time remaining. In other words, when the moment in time at which the occurrence of a given event (for example, on-time completion of a project) will have been proven to be true or false is known in advance, its plausibility is determined by the resources attempting to ensure its occurrence, the obstacles that could prevent it, and how much time remains before it either has occurred or is no longer possible. Naturally, then, this only applies to occurrences where time is a factor in the definition of the occurrence (other examples include election results and sporting events). Hence, the impact of time in this equation is obvious: as the amount remaining approaches zero, so does the plausibility of the occurrence. At first glance, however, there seems to be one problem with this equation: once T = 0, so does P. This would seem to imply that no event can ever be plausible, because time always runs out. But that's precisely what makes the other two factors so crucial: they can be controlled; time cannot (since this equation measures plausibility in a single snapshot of time, extending a deadline would theoretically increase plausibility by changing the amount of time remaining... except that the original event - completion by the original deadline - is no longer in consideration).

R and O are almost as obvious as T, but a lot is encapsulated into each of these single-character variables (the observant will hopefully have noticed that my equations differ in at least this respect from my coding conventions). As O approaches zero, P approaches infinity. This is what allows time to decreasingly be a factor: if only one obstacle remains, and sufficient resources are available, the event remains plausible right up to the very end. And once it has occurred, its plausibility is no longer meaningful data: it has gone from possible to actual.

To maximize plausibility, then, the goal becomes minimization of obstacles and maximization of resources. Sadly, this is not as easy as it may seem. A mistake too commonly made in managing projects is to throw "warm bodies" at the effort, assuming that more people automatically means more progress. In reality, the less qualified or informed a given team member is upon their introduction to the project, the more time is spent transforming an obstacle disguised as a resource into an actual resource; the time remaining before the project's due date inches (or races) towards zero, and so does the plausibility of on-time completion. In programming, the use of existing libraries or frameworks can present a similar paradox: if the existing codebase does not provide an API so intuitive that all project members can hit the proverbial ground running, time must be spent (hopefully in diminishing amounts as familiarity increases) learning how to use what was written by someone else; time approaches zero, and so does plausibility. If you've ever heard (or said), "it's faster if I do it myself", or, "it's faster if I write it myself", you know what it's like when the distinction between a resource and an obstacle is not as clear as we might sometimes wish it to be.

One interesting implication of this is that scope and quality are actually both obstacles. I've seen and heard this statement in various forms over the years: "you can have it fast, good, and cheap, but you have to pick two." I'd probably add "well-documented" into that mix as well. If you've only got one line of code left to write, on-time completion is fairly plausible, even if your deadline is only five minutes in the future. On the other hand, if the project isn't considered delivered until you've completed 80 hours of paperwork not yet begun, P would be an extremely small number... even though in theory 960 people working for 5 minutes would perform 80 hours of work, in practice we know that approach would be a terrible idea. Similarly, adding features to the request constitutes an increase in the amount of obstacles (in the form of work to be performed and, typically, new challenges to be overcome). Hence, increasing the scope without adjusting the resources or time automatically lowers the plausibility of the deadline being met; assuming the original estimate was reasonably accurate, the only plausible way to meet the deadline is to sacrifice quality. Introduction of other obstacles mid-stream, such as holding several hours of staff meetings each day to ask the developers why they're not making more progress when they could instead be at their desks making progress, will also inevitably result in a reduction in quality, since the only recourse left to each resource is to "rush the job". This is similar to the way a motorist's quality of driving suffers as a result of poor planning or unforeseen obstacles, such as reckless speeding to make up for lost time or cutting across several lanes of traffic at once if they've been boxed in until right before their exit. A myriad of seemingly inconsequential decisions earlier on could have removed those obstacles before the deadline approached, but the consequence of those decisions is that quality suffers.

Which I suppose is why I spent so much time thinking (and now writing) about this topic: while these principles are proven on a daily basis in our industry, I've only recently been noticing how universal they are. Countless decisions I make each day determine what I'll be able to commit to later, the quality of my relationships, and my sense of self. I'm hoping to be increasingly mindful of that over time.