A colleague of mine and I were working on some software today and we stumbled across a use case we'd missed during the planning stages of the task.
My cohort remarked, “If we'd spent more time in requirements we could have caught this, we need to be more thorough next time.”
Whenever this assertion is made, I'd like to throw out the following questions:
- At the time we decided to move on to coding, we thought we'd been thorough. What could have we done then to make ourselves more thorough? How do we unconvince ourselves we've not done a good enough job when we think we have?
- If we answer the previous question concretely, is that option cost effective?
- What is the bottom line cost we are currently incurring due to not being thorough enough previously? Is it anything tangible beyond the desire to do better?
I really like the “how do we unconvince ourselves” question. Many times when we decided to make the transition from planning to coding we were convinced, and if we could really go back without knowledge of the future, we'd make the same decision 10 times out of 10. Remember, that's just how learning works and LearningIsGood.
Sometimes we were convinced due to shear boredom/exhaustion of being in the planning process without trying to get some of the results nailed down in code.
Sometimes if we're honest with ourselves we weren't really convinced, but we were lazy or sloppy, and we should look back for improvements.
Bottom line, it's good news that many of us want to get the job done right the first time. The bad news is that job we do is a hard one, and we frequently just can't get it done right the first time. I'm all for retrospectives and looking for ways to help think things through ahead of time, but I'm also for AgileDevelopment, which gears up for the oncoming change, attempting to deal with it so that when it comes (and it will) it's not really a big deal.
tags: ComputersAndTechnology SoftwareAppreciation
