Never discuss dates with software engineers

Never discuss dates with software engineers.

I'm not talking about how to handle dates or calendars in code or a library, by all means start that argument at your leisure.

I'm talking about asking engineers to estimate when features will be expected, or forever reminding engineers of dates previously promised, or demanding engineers say what value will be delivered when.

Software Engineers are notoriously good optimisers. Given the right environment, structure and conditions they will optimise for the things their customers value most highly, for example product quality, delivering incremental value quickly and sustainable addition of features over the medium or long term.

If, however, the conversation between engineers and their customers, or engineers and engineering management, primarily revolves around dates then engineers are going to start optimising for dates.  So much so that the things above that customers care about will soon be a secondary concern, or worse still not be a concern at all.

Observations

Engineer asks "what do we need to do to call this “technically done” by date X?" i.e. what corners can I cut to call this done by date X.  Cutting corners in software you need to rely on or extend will lead to later cries of “hard to maintain” or a general view of the software delivering a poor user experience.  

Engineers “technically” deliver a feature by date X as described above, cutting corners to do so.  The corners cut have started biting, it is now terribly embarrassing to have to go back and work on a feature previously declared complete.  All pressure and inertia from your date driven process leads you to leave the feature in a poor state and move on to the next delivery by the next date.

“Let’s be conservative when estimating, don’t commit to too much to make sure we hit our dates”.  Engineers being deliberately unambitious with their work so they can say they reliably hit dates, or otherwise hiding valuable work from official planning processes that is difficult to estimate.  The focus is on dates, to the point of distraction from solving the problems at hand.

If a delivery comes in earlier than expected, or if new requirements or requests come in on the fly, how do you select what to work on next?  You could say no to new requests as you’ve already committed to some dates on a plan.  Should you respond to this new request if you are already half way through some delivery?  Having dates written down skews this decision making, causing teams and managers to focus on dates, not on value and priority.  I’ve also seen many teams try and squeeze additional requests into work schedules whilst nominally keeping to their commitments, either by delivering commitments through crunching or not delivering to the quality they hoped for.

Ever heard someone say "death by a thousand cuts" with regards to internal tool quality or tech debt or, in the worst case, about the product you’re building? Probably a sign that a set of engineering teams have collectively "hit" one thousand dates. The set of engineering teams here are not at fault, they are dutifully optimising for the primary topic of conversation or concern, they are optimising for hitting dates.

Conspiracy

I have been in situations where the demand for dates and estimates has come solely from the management structures around or above Engineering teams, and not from the Engineers involved, users or customers. As an engineer or engineering manager it’s hard not to think of demanding dates and estimates as a way to whittle a mallet with which you’ll be clubbed later should you miss any of them. I have been in organisations where this threat has been explicit. Team and individual performance management by dates only shortens your path toward the observations above.

Every date written down for the delivery of a dependency offers dependent teams and managers the opportunity to disengage, abdicate responsibilities, or delegate blame.  A “commitment” via a date if missed for one of your dependencies can be your excuse as to why you’ve missed a date that you have promised.  Why question the realism of a promised date, or engage with that team any further if you can simply assume that a feature will be there on the committed date?  It may seem like this delegation of responsibility via a date allows an organisation to scale (perhaps this belongs in the empathy section), I would counter with there being a scoping or ownership problem within teams or organisations if they find themselves planning around the “structure” of delivery dates.

Empathy

A series of dates next to features and capabilities being available does look an awful lot like a plan.  No one wants to be caught looking like they don’t have a plan, so writing down a series of dates next to features stops people from asking awkward questions should things take longer than expected.

Many off-the-shelf processes (Scrum etc) emphasise dates and estimates. These processes are well documented and used widely in the industry.  Straying away from them may seem risky.  No one wants to explain themselves if something is taking longer than expected that they are off-piste from mainstream planning and software development processes.

There are times when new requests are piling up as environments change, or business demands vary.  If you can point to dates you’ve already committed to, you can defer those requests to a later time or sprint.  This might help you maintain momentum on the development of a feature. If you can’t point to your plan when new requests come in, you might think you’ll get steamrolled into reacting and picking up new work too often.

Plans in the form of features next to dates have a habit of going “viral”, anchoring expectations when doing high level or detailed planning.  Momentum and inertia builds around delivery dates, making it seemingly more difficult to change if other plans now depend on dates you have, perhaps accidentally, shipped.  

Dates can offer the illusion of finality.  “Finishing” something by a set date can mask the later maintenance and support costs of a product or feature, making work easier to sponsor or fund if the conversation focuses around delivery by a certain date.

Action

Choose processes that emphasise priorities and aim to deliver value incrementally and often.  Avoid processes that emphasise dates and estimates.