But I Don't Have Time!

"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 our 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, when my colleague 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 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 happen 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 parts of the map that are labeled "Here There Be Dragons."

I know someone who begins every new project by studying his organization's "lessons learned" repository. Then he charts a course based on the footsteps of those who have passed before. A project manager who doesn't have time to peruse the lessons 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 a requirements specification." This person is relying on a mind meld to substitute for oral and written 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. Similarly, some customers resist participating in requirements elicitation, proclaiming that, "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 feedback eventually. It's a lot less painful to get it before you've actually 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 would find plenty of time to rearchitect the system later when he couldn't satisfy the performance requirements. "We're doing rapid development here, so I don't have time to document my designs and code," is another developer mantra. Amazingly, maintenance staff (who are sometimes also the original developers) always seem to have time to reverse-engineer the design and requirements from the code when they have to make a 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 she really be saying, "I'll have lots of time later to refactor my initial design, thereby asymptotically approaching acceptable performance and satisfaction of the important quality attributes"?

What shall we think when we hear a developer say, "But I don't have time to hold a code inspection"? Does the developer believe that he'll need the time he saves by skipping the inspection to fix the bugs that the testers find in his code? Odds are he'll need many more hours for debugging than if he had subjected his code to the scrutiny of some colleagues before unleashing the testers on it.

From Everyone
You may not think you have time to spend on process improvement, either, but we all want the benefits of improved productivity and quality that can come from changing the ways we work. One seminar audience complained that they were being asked to do more work with fewer people. When I asked what the organization was doing to enable this outcome, the reply was "Nothing." There's never a convenient time to take the actions that 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 thorough requirements development, iterate on your designs, and review your code. That is, do all those things that people erroneously argue take too much time. When someone is debating the importance of these quality activities, you can respond, "But we don't have time to cut corners."