(Artificial) Haste (Still) Makes Waste

Writing about the old internet quiz he recently retired, Justin Searls of "Searls-Briggs Type Indicator®" fame analyzed the statistics that years of leaving his "workplace horoscope" questionnaire online yielded.

Aside from being an amusing read, his "16 Things You Believe About Software" is also a distillation of the conventional wisdom of a more thoughtful than average cohort.

My favorite points to ponder were the second and eighth points, which are Don't hold back details, show us the big picture and Aggressive deadlines won't get it done faster, respectively.

I'll admit feeling vindicated by seeing my own opinion being held by a group of professionals I respect, but these points are worth thinking about. And they're related, as can best be seen in Searls's comments on deadlines:

Great for goading animals, poor for inspiring humans. (Image by the U.S. National Park Service, via Wikimedia Commons, public domain.)

Before we founded Test Double, I read Pragmatic Thinking and Learning by Andy Hunt. It's a brisk read, but -- and I mean this as high praise -- by 2023 most of its points have become well-trodden, familiar territory. One phrase Andy used when summarizing how creative thinking is blunted by the human stress response wedged itself permanently in my brain: "pressure kills cognition."

I empathize with the project managers tasked with completing software projects within a given time constraint. First, Fred Brooks quipped in the 70s that, "adding manpower to a late software project makes it later." Now, a growing body of research shows the most surefire way to doom a project is to put undue pressure on the people you already do have. Once things start going sideways, there are only so many knobs to turn and, try as you might, you can't push on a rope. [links omitted, emphasis in original]

My only quibble here is that Searls could have stood to add undue to pressure kills cognition: If something really does need to be done by a given time, it really needs to be done by then, and one can think of that as part of its specification.

Having to work quickly will always be a challenge, but having a solid reason for being in a hurry is a whole different animal than being put on a short timeline for no apparent reason at all.

I'm not just in the programmers' amen corner here: A couple of recent experiences with ridiculous deadlines have really made me think about how I can push back the next time I find someone jerking me around this way.

Just off the top of my head, the deadlines: caused the quality of my work to suffer, set priorities I didn't agree with (for what turned out to be very good reasons), caused me unnecessary stress about the work and annoyance with the person's arbitrary or unexplained constraints on my time, and ended up costing me time compared with how I would have proceeded left to my own devices.

What would I do differently in the future? In essence, it would be to push back against the deadline, or at least get the person setting it to explain what the big hurry is.

If there is a good reason, I can bake it in to my thinking. If not, that problem is out in the open, and less likely to reflect badly on me. In fact, in the latter case, there might be space to say I told you so, should the arbitrary hit the fan.

-- CAV