--- title: "Immediate and delayed satisfaction in software development" url: "https://www.5whys.com/articles/immediate-and-delayed-satisfaction-in-software-development.md" canonical: "https://www.5whys.com/articles/immediate-and-delayed-satisfaction-in-software-development.html" published: "2009-09-10T23:34:44+00:00" updated: "2009-09-13T22:10:32.027000+00:00" tags: ["Decision Making", "Ri", "people patterns"] author: "Roy Osherove" description: "Why software teams should not accept slow builds and manual work, and how leads who can't stand delayed satisfaction push for automation and fast releases." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Immediate and delayed satisfaction in software development All our lives we're told a mantra that keeps repeating itself. We hear it as children when we want an ice cream, and we hear it as adults when we want that brand new car, or that holiday vacation: > Have some patience But in the software world - things become a bit chaotic. Your boos wants things done **now**. The customer wants things done **now**. Not later, not tomorrow.  So what do we tell our customer? > Have some patience (and these changes you wanted tomorrow can wait 6 months) What do we tell our boss, though? > Um, OK. I think we might be able to do that! That's right. We succumb to our own feelings that we _want_ to be able to do anything quickly, so we say we will (but we never do, do we?) ### Why don't we ever get to that point where things can be done **now** in software?  There's a simple answer: We are letting ourselves be patient with our development process and tools. We allow **waste of time** when we build the things that we promised our boss we'll deliver **now.** - When we want to release a product we get told that it will take 3 weeks to make sure everything works - so what do we tell ourselves? > Have patience - When our machine has bluescreened for the 3rd time today, our source control takes 10 minutes to get the latest version of 2 files and our team keeps finding bugs manually by debugging - we say one thing to ourselves: > Have patience Somehow, we have convinced ourselves that in software, like real like, there are certain things you must take for granted (death and taxes). things you can't fight, so you shouldn't even try. We fail to realize that in software, like in The Matrix, rules can be bent. Things that take a long time can be automated. Things that are hard to do can be made easier with tools (or by removing tooling!) People who cannot live with delayed satisfaction in the real world, suffer from the environment, since some things, they learn, are simply going to have to wait. they may feel more negative about things, they may seem pushy, abrasive and ill mannered, but they are just troubled by a built in lack of what psychologists call "Optimal Frustration" - the ability to wait for what you really want, and still feel OK about it. Funnily enough, in Software, those same people can be tremendously successful team lead, due to that exact lack of ability to endure delayed satisfaction. Thos eare the people that keeps asking qustions like these: 1. "Why can't I have a working build with installer at the push of a damn button?" 2. "Is there a reason you invited me to this meeting? you're wasting my time" 3. "Why do I have to login to my computer to see how the team is doing?" 4. "WHy are we still doing this manually?" and so on. eventually, what these people drive is the ability for an organization to not delay its satisfactions - when they want to release something, they can do it on a whim. When they want to fix a bug and send a patch to a customer, they can do it without a hassle. if they really want to, they can fix something that just came in as high priority in the **middle** of an iteration and not even flinch. ## Read next - [How to deal with bad decisions made by the team](https://www.5whys.com/articles/how-to-deal-with-bad-decisions-made-by-the-team.html): How a team lead can steer a self-directing team away from bad technical decisions by asking hard questions, based on Mike Cohn's Succeeding with Agile. - [How to squeeze a decision out of a sleepy meeting](https://www.5whys.com/articles/how-to-squeeze-a-decision-out-of-a-sleepy-meeting.html): A link to Yves Hanoulle's short post on a simple protocol for squeezing a decision out of long, tired meetings that never seem to reach one. - [Why managing a software team can be more effective than "regular" management](https://www.5whys.com/articles/why-managing-a-software-team-can-be-more-effective-than-regu.html): Roy Osherove argues that leading a software team differs from regular management because automating builds, tests and deployments removes fake barriers. --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/