When developing software there are countless nuances to consider, about how business operates. These lead to lots of suggestions and ideas for how the software should behave in various situations. You might find yourself wondering, how do we deal with X, or what about Y, or don’t forget about Z. The extremes of these are along the lines of “What happens when lightning strikes our ice cream store in the middle of winter, how will customers continue to order ice cream cones?”
Software professionals steeped in a hierarchy of taking marching orders and carrying them out waste no time and get right into the details. “Well we could detect a lightning strike with … and then we could divert to … so customers can continue to order ice cream cones.”
Sadly, many of these nuances are irrelevant, yet are incorporated into the software anyways. This often leads to paralyzing complexity. Simple reflection can help identify this waste. If you’ve been a part of software development, look back at several of the bigger projects you’ve worked on, make a list of the situations that were incorporated. What value did these nuances provide, was it worth it?
To avoid wasting time in nuances, I recommend treating every idea, suggestion, and possible situation that software should handle, as suspect. Treat all scenarios as guilty until proven innocent, in other words, all scenarios are unnecessary until proven otherwise. That way, before anyone makes a mountain out of a molehill, people have to step back and ask a few questions to ascertain the value of considering the scenario. Here are the questions I recommend, I use these routinely:
- For suggestions and ideas (wouldn’t it be nice if the software did X)
- What would that be used for? (find out who, what, when, where, how)
- What’s the purpose of that, what does it help accomplish? (why)
- Does that purpose align with the objectives of the current project?
- Is software really the best way to handle this? Given an understanding of what the consequences of not considering it in the software?
- For scenarios and situations
- How often does this happen?
- How does this relate to the purpose of the objectives of the current project we’re working on?
- What would happen if we did nothing?
- How is this handled currently?
- Is software really the best way to handle this? Given an understanding of what the consequences of not considering it in the software?
The objective of these questions is to ascertain the value of handling a particular situation. To prove the suggestion or situation is necessary for consideration. If at any point it seems like it’s unnecessary, abandon it and move on. If however, it proves to be worthwhile beyond reasonable doubt, then dive into the details with a clear understanding of the purpose. Use your new-found understanding of purpose to guide you.
For bureaucratic reasons, armies of software professionals feel that their job is to handle every possible situation regardless of the cost to do so.
For bureaucratic reasons, armies of software professionals feel that their job is to handle every possible situation regardless of the cost to do so. Software doesn’t exist to handle every possible scenario in business, it exists to create value for customers, employees and the organization. What becomes a part of software has to be worthwhile.