But I Don’t Have Time!

(image adapted from Lukas Blazek)

“If you don’t have time to do it right, when will you have time to do it over?” I internalized the message on this sign in my high school chemistry class. Cutting corners and skipping steps saves you time today, but often you pay a much greater price farther down the line when fixing the problems caused by haste.

This is especially true in the software industry. Overworked software people often push back against suggestions of actions they might take to improve their chances of project and organizational success. They protest, “I’d really like to do that and I know I should, but I don’t have time.” But what’s the real message? Let’s see what the refrain of “But I don’t have time!” might really mean.

From Managers

“But I don’t have time to hold a retrospective,” declared the manager of a recently failed project. My colleague had just suggested that it might be a good idea to reflect on what went wrong before they launched a second attempt. You could realistically interpret this project manager’s message as, “We must get started on the next project immediately because it will take us so long to recover from making those same mistakes again.”

“But I don’t have time to identify risks and decide how to control them,” another manager complained. He might have been thinking, “None of the bad things that happened to other people will happen to us.” Hey, the risks are out there whether you choose to look for them or not. My personal preference is to fill in those unknown parts of the map that are labeled “Here There Be Dragons.” You know, just in case there really are.

I know someone who begins each new project by studying his organization’s lessons-learned repository. Then he charts a course based on the footsteps of those who have passed — and suffered — before. While he’s doing that studying it looks like he isn’t making progress. Others might wonder when he’s going to start doing some actual work.

As it turns out, he’s one of the most efficient workers I know because he learns how to navigate through the minefield before he sets sail. A project manager who thinks he doesn’t have time to peruse the lessons already learned has opted instead to wrestle with some of the same problems that previous managers have experienced.

You might have heard a manager say, “We don’t have time to write requirements.” This person is relying on a mind meld to replace clear communication of the new system’s requirements. The translation might be, “We need to start coding immediately so we have time later to change the system to really satisfy the users.” This just doesn’t seem efficient to me. Remember, the hard part isn’t writing requirements. It’s figuring out what they are. The cost of recording knowledge is small compared to the cost of acquiring that knowledge.

Similarly, some customers resist participating in requirements elicitation. Customers have actually told me, “I don’t have time to talk with you about my requirements. You should already know what I need.” The clear message is, “The developers can use telepathy and clairvoyance to understand my business needs. If they miss the mark, I’ll straighten them out after I see what they build as their first guess.”

You’re going to get the customer input eventually. It’s a lot less painful to get it before you’ve delivered the product.

From Developers

“I don’t have time to do a technical feasibility evaluation,” argued the harried developer. What he meant was that he’d find plenty of time to re-architect the system later when he couldn’t satisfy the performance requirements.

“We’re doing agile development here, so I don’t have time to document my designs or code,” is another developer mantra. Amazingly, maintainers (who sometimes are also the original developers) always seem to find time to reverse-engineer the design and requirements from the code when they have to make a significant change.

I get nervous when I hear a developer say, “I don’t have time to do a bunch of design work. I need to get something running right away!” Could he really be saying, “I’ll have lots of time later to refactor my initial design, thereby asymptotically approaching acceptable performance and quality goals”?

To me, a synonym for design is thinking. A key to successful design is iteration, and you can iterate a lot faster on concepts, models, and prototypes than on completed software.

What shall we think when we hear a developer say, “But I don’t have time for a code review”? Does the developer believe she’ll need the time saved by skipping reviews to fix the bugs the testers find in her code? Odds are she’ll need many more hours for debugging than if she had submitted the code to her colleagues’ scrutiny before unleashing testers — or users — on it.

From Everyone

You might not think you have time to spend on process improvement activities, either. But we all want the benefits of improved productivity and quality that can come from changing the ways we work.

The attendees at one of my courses complained that they were being asked to do more work with fewer people. When I asked what the organization was doing to enable this grand productivity increase, the reply was “Nothing.” It’s not reasonable to expect better outcomes without giving people the knowledge, techniques, and tools to achieve them. There are no magical shortcuts, spells, or potions.

There’s never a convenient time to take the actions we believe will pay big dividends. But the inconvenience of later fixes generally comes back with a vengeance. All you’re doing is passing the inconvenience along to the customer, and then back to your developers when the complaints roll in.

To save time and money, beef up your development and management practices, invest in thoughtful requirements exploration, iterate on your designs, and invite peers to review all of your work products. That is, do all those things that people mistakenly argue take too much time. If someone questions the importance of these quality activities, you can respond, “But we don’t have time to cut corners.”


If you’re interested in software requirements, business analysis, project management, quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Author of 12 books on software, design, management, consulting, and a mystery novel. Guitars, wine, and military history fill the voids. https://karlwiegers.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store