Speaking truth: why “when we’ll be Done” is unknowable

Another challenge in managing software teams to outstanding performance derives from the tawdry custom of decreeing the future date a software system will be “done” (which usually means a compete feature set delivered and operational). If only wishing could make it so. Prima facie: every target date is subject to myriad uncertainties, changing demands, and rapidly shifting forces. Each day does unfold a bit differently. Every future date is a statement of hope, not fact -- especially not in the realm of new product development.

In these situations the manager decides whether to speak in terms of facts or in terms of hopes. A guess must be seen for what it is -- a conjecture, a speculation, a bunch of B.S. In the milieu of some workplaces, dates (i.e., “when” speak) drowns out other topics. At times, “date-debate” becomes a cesspool of political stratagems. In truth, only the roughest and broadest date range can be guessed. Expecting guarantee of a firm date for a particularly scoped set of features is silly to be sure. It is economically damaging to be certain, especially as dependencies grow around those expectations. Efforts that will likely become wasted are initiated, all based on hope. You can be smart about this, but that takes backbone.

Big plans, long-term visions, and the next big thing, are much more hope than fact: dreams and schemes are more likely to remain wishes than to become a reality. What else could new product development be other than … uhm … new. New product development is exactly that: something that has never been done before. Expect surprises. Otherwise don’t expect anything new. It’s one or the other: new or old.  The future isn’t predictable in any manner that matters for most software services/products in a place where projects shift directions, personnel change, the market shifts, new technologies appear while others become obsolete faster than planners anticipated.

It’s fascinating to see how often product managers want to be able to iterate on their designs, but don’t comprehend that in order to accommodate that, then developers likewise need time to adapt the code by iterating and refactoring. Product managers often attempt to fix a date on developers but not on themselves. Instead, the product manager should prioritize either a date or a feature set over the other -- it’s not possible for them to be equally important. Which takes priority? If it’s the date, then cut to fit. If it’s the scope, then keep everyone apprised of progress so they know when to leap into action.

It’s somewhat comical to watch how marketing and PR will be quick to talk about the constraints of their lead times -- which are typically small and predictable. Yet, they often want engineering to specify a fixed date far in the future. They’ve got it backwards. If marketing needs, say 6 weeks lead for printing and distribution, engineering can easily let them know 7 weeks in advance. What can’t be determined (as fact) is what things will look like 5-6 months from now.

Having an important business need doesn’t translate into software development becoming predictable on a scheduled timeline. Authority and command cannot make it so. All they can do is pressure someone to lie. To Speak The Future Date (in new product development) is to knowingly speak falsely. That’s the genesis of many problems, much stress, low morale, and employee turnover.

Others then come to depend upon that date as if it were real, expecting the complete feature set as a given (never mind it probably hasn’t yet been really defined, and PMs will want to tweak it as time goes on). Worse yet, personnel then face having their performance judged on whether they made the fiction come true -- which they can (once), of course, but at the cost of incurring substantial technical debt, delivering bug-infested and undocumented code, and thus sending huge costs downstream that vitiate an enterprise’s capacity for future innovation due to induced burdens such additional maintenance, support, and forced deprecation.

Spurred on by the quick half-life of software projects, of product shifts, and of staff changes, the codebase quickly becomes calcified and brittle. Acting only one step ahead leads to a “hackolution” instead of an “evolution” of the codebase. Continual piecemeal hacks optimize for the here and now, yet flexibility tomorrow means preparing for it today.  In part, that means that recognizing that its less expensive to build in monitoring and testing today than it is to waste much time debugging and fixing in the future.

By nature, short-term actions prevail to the degree they’re rewarded. The short term can be good for the software author, for the product manager, for the marketing manager, but not as good for the company itself. For the longer horizons of the company, the manager is obliged to remain mindful of the economics of the codebase, thereby keeping a mental tally of its value, burden, and opportunity costs in light of development activities underway.

Balancing the short and long term is delicate and unique in every situation. In each case, the business needs, the available personnel, the project resources are different. Nonetheless, good engineering practices today makes for a better system tomorrow.  Developers can easily become “too clever by half” to speed up code development -- something that can save half a day today may well cost two or three days to find and fix down the road in six to nine months or so. An unreasonable demand for a feature by a date can induce this behavior easily. Often, managers are the ones who actually create the downstream problems by lacking discipline at this point.

Haste today often precludes innovation tomorrow. Promising silly dates for feature-replete products yields premature dependence on fragile infrastructure. Burdensome downstream expenses accrue. Although an early release may be opportune for marketing purposes, it may also become crippling burdensome to the company over time. For a company that wants to last, or just not become a one-trick pony, prudence cautions managers to apprise every project’s performance in terms of both value today and opportunity for tomorrow.[1] Focus is served by ensuring everyone knows what matters most. A conscious choice is the responsible thing to do.

A real pernicious circumstance occurs from bandying about hopeful dates without recognizing actual capacity or necessary features/scope that can likely be ready by that date. The cost endured here is more subtle and more damaging than those mentioned above. Discussions of “dates” changes the milieu of the workplace -- thoughts shift from “what we are working on”, to who’s talking to “me” and when “I” am expected to be done with something that probably hasn’t yet been invented or defined. The predominant outcome from “date posturing” is to distract developers from their work. As a result, people become unsettled, and each developer’s thoughts naturally become drawn to conjuring up worrisome fictions, and fretting over the future. Like an evil Gresham’s Law of conversation, the  milieu spawned from “when” chatter is combustible and predisposed to political shenanigans. Team performance becomes suppressed. Every person, for survival, optimizes for the self.

Commitments to future dates ask people to claim and then stand behind statements that are known to be speculative guesses. These are circumstances with capricious career impacts, either good or bad. No productive value is afforded by this focus, by this claim on attention. Whereas a plan of record is sensible, a date of future record is folly. How else could it be? Such talk of dates is the slippery slope that rapidly transforms a collaborative workplace milieu into one best described as “me first”. Heroes are bred here. Kiss teamwork goodbye. Recurring discussions of “when” foster rampant worry unless the discussion are accompanied by notions of “cut to fit”. That is, to have conversations that reflect pragmatism regarding what can actually be accomplished by that sacred date. In themselves, dates are fine -- it’s the unspoken baggage of feature completeness that is the hidden toxin.

Coding is an exacting, by-hand, attentive practice akin to the work of the finest artists and craft masters. Even tiny systems are built in pieces by different people, often with myriad small and interdependent parts. The economic value of that software is shaped by how well this blizzard of components and their relationships work together, and how costly it will be maintain or rewrite. Of the myriad uncertainties in software development, the human element clearly predominates. Such is ignored only by folly or snoozing or conniving.

But there a practical solution to this: pick which is more important -- the date or the feature set, then plan accordingly. It can’t be both.

US President Teddy Roosevelt offered plain-speaking guidance: “Do what you can, where you are, with what you’ve got.” What you as the manager can do is to speak in present tenses and keep everyone’s focus on “what” needs to be done. Shield the developers from the allied roles or executives clamoring for “when.” Stay alert enough to bring witness to shenanigans. Have the backbone to expose them to sunlight. You’ll get more done, and the developers will be a happier lot.

[1] From the vantage point of this author, “quickies” are necessary for startups and early stage companies, but notable deleterious to  those orgs with greater resources, longer horizons, and larger workforces. Sadly, it seems at least, so many of this “next stage” orgs act according to the circumstances they used to be in instead of where they are and have evolved to.