What Do We Know About Time Pressure in Software Development?

About 10 years ago, I worked on a large, multi team (multi-org really) project that was run using TOC (Theory Of Constraints). Put very very very simply, every team was told to give honest, buffer-less estimates for their primary work areas, and then a global project buffer was added as a factor of the sum of estimates. At any point in time, we worked as if every single thing would line up perfectly, so upcoming milestone targets would often feel crazy or unlikely. But people being eager to please, and mostly unwillingness to be the one team blocking the entire project - meant that folks worked hard to meet some of these targets. It was extremely hard. It was a bit stressful. It felt crazy at times. But it got done in half the time I would have initially expected such a complex project to take. To me, the most impressive thing about it all was that the project leader drove us all quite hard but was super cool - he explained that he wanted everyone to be open and honest about blockers so they could be moved with the full force he was given, and that actually, his way of measuring project progress was the rate at which schedules slipped.

This article implies, but doesn't come right out and say, something that I strongly suspect: that producing an accurate (or even close-to accurate) software project estimate is a time-consuming, unpredictable task. The question nobody seems to be examining is whether or not the cost of doing a large, expensive up-front analysis that might take an arbitrary amount of time is less than the cost of just doing it concurrently with the software development itself.

Treating every project as if it&#x27;s in emergency mode is a great way to burnout the team and get shoddy work results.<p>Another idiotic practice is multitasking since context switching introduces tons of overhead.<p>And tying it all together, the importance of a project determines its resources. A truly critical task needs 100% focus. If a manager isn&#x27;t willing to assign a full-time employee to a task, then that project isn&#x27;t critical.

&gt; The Yerkes–Dodson law refers to an inverted U-shaped relationship between performance and arousal, where performance increases with arousal, but only up to a certain point.<p>The quest to discover and apply &quot;laws&quot; like this courts disaster or disruption because people are neurodiverse. ADHD people respond to deadlines in a completely different way to non ADHD - sometimes inversely, sometimes obversely, and so require different management. Same but different with autistic spectrum people, introverts, extroverts, bipolar, insomnia, sleep apneates, diabetics and long covids.<p>It may be tempting to dismiss neurodiversity as a fringe consideration and just assume most people are &quot;normal&quot;, but their circumstances, both in the workplace and beyond it, may complicate Yerkes-Dodson as much as neurodiversity whilst evading detection by managers and systems.

Well written and thorough article, but I can&#x27;t help notice if this isn&#x27;t just reverse engineering a standard MBA curriculum.<p>&gt; Time pressure is also reported to be the most frequent external cause of unhappiness among developers.<p>&gt; The inverted U-shaped relationship is one typical example of this, which means that time pressure increases efficiency up to a certain point, but after that increases in time pressure cause a decrease in efficiency<p>A good manager knows how to sustain just the right amount of pressure.

&quot;If you want it bad, that&#x27;s how you&#x27;re going to get it.&quot; That is, time pressure kills quality.

<a href="https:&#x2F;&#x2F;dilbert.com&#x2F;strip&#x2F;2022-01-02" rel="nofollow">https:&#x2F;&#x2F;dilbert.com&#x2F;strip&#x2F;2022-01-02</a>

&gt; [In this article, time pressure refers to both budget pressure, e.g., eight hours (budget) to do a task, and schedule pressure, e.g., a task that must be done by tomorrow.]<p>Aren&#x27;t these the same thing? the latter being somewhere around 24hours give or take

Maybe this will be hugely impopular, but in addition to the three causes mentioned, isn&#x27;t it possible that one cause actually comes from developers simply not performing?<p>If comparing to sports, in a team, is it always the coach&#x27;s fault? Or is it possible that one player is not performing as expected? Is it then the coach&#x27;s issue that he&#x2F;she didn&#x27;t expect that?

At the beginning of my current job (I joined as CTO) I had to inherit a lot of misunderstandings that the management team had.<p>They had hired people who knew nothing about building software (before me joining), most likely those people have never really built and shipped anything. Everyone on the management was under the impression that software is easy and everything needs to be delivered on time and if it&#x27;s delayed we need to throw more money at the problem and that would solve the problem. They would continuously ask for &quot;timelines&quot; and never understood the word &quot;estimate&quot;. They knew the definition of the word but could never accept the reality of the definition.<p>I was tasked with building a brand new core banking engine and a kyc engine. I talked to the existing tech team that was there and none had ever done anything complex. Mostly they just knew how to write some basic PHP pages to do some simple tasks like rendering a CSV table for a specific report etc... So they needed to first be trained.<p>To cut a long story short I was the only one on the team to be able to write productive code to build such a complex system. I hired someone who could write code to help train the existing team. However given the complexity of the problem and the tight timelines I had to solve. I basically did the design and implemented about 70% of the code myself while my other teammates were being trained. This also included building a KYC engine along the way. I remembered suffering immensely building the engine and hiring &#x2F; building the team. I would focus on working with the team during the day and coded at night, since that was the only time I could get un-interrupted hours to code.<p>I worked til 2AM almost every night for 7 days a week for over a year (6 months to get it to launch and then refinements &#x2F; continuous improvements after). To complete the engine and get it to serve hundreds of thousands of transactions every month. I was never paid for overtime. Today the company stands strong with handsome profits.<p>Trust me. I can tell you, the problem is not the developers &#x2F; process &#x2F; agile &#x2F; kanban &#x2F; etc..., the problem is management. It&#x27;s always management. I was able to get management to understand the true scope of the task by stopping working overtime and standing my ground (when the company had recovered and was able to produce a stable income to support itself).<p>The overtime I did hid away all the &#x27;complexities&#x27; and the &#x27;debt&#x27;, and prevented the company from learning. I basically ended up paying for the company&#x27;s mismanagement &#x2F; toxic culture with my time. Fortunately a lot of toxic people left the company, a growing company will generally push out the non-performers organically. It took a lot of effort on my part personally to resolve issues plaguing the company, establish an engineering culture, build a strong tech team that can withstand pressure and deliver continuously and can build on top of the framework I provided.<p>The lesson has always been. It&#x27;s never the software team (at least never the team I manage) whom are not productive or doing their best. It has always been management &#x2F; company culture &#x2F; never truly understanding the scope &#x2F; requirement enough to understand how huge of an undertaking a given project is. I can tell you without a doubt this article pretty much hit the nail on the head. I&#x27;m living proof and have the battle scars to prove it.<p>Now I tell management about time estimates as it is. &quot;No fixed timeline, the team estimate, the team builds, it&#x27;s done when it&#x27;s done, live with it or fire me.&quot;<p>I&#x27;ve fortunately afford myself the position to be able to deliver the truth serum to management and they have no choice but to accept it. It didn&#x27;t come cheap, I&#x27;m still scarred.

Where we are going, we dont need no time. :P <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=26aUmDvDROE" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=26aUmDvDROE</a>

TL;DR, literally, I didn&#x27;t bother to read the whole thing. Time pressure will never go away. It only takes common sense to realize that those who want something, i.e. are paying for it, want it as soon as possible. The difference from making physical things is the perception that software is soft: it seems to be infinitely malleable and all it takes is hand waving magic or sheer willpower to manifest it. This is of course the lie that those building software understand, and those that do not, will not.

Yes.