Temporary Solutions can be more permanent than Strategic Solutions

I know we have all been there before. We get an urgent request that flies across our desk talking about a temporary and tactical solution we absolutely need to do. It is followed by explanations on why it is required and apologies for the non-standard solution. Usually it is required due to some last-minute sale or promise made by C-level person.

And then we get the Software Development equivalent of “Of course, I’ll call you tomorrow…”

“It is only a temporary solution, we won’t have to live with the solution for long”

The Two Truths

There are two undeniable truths about this situation:

1) It is required

There are many business solutions that are not pretty or perfect. Many business solutions would not be cost-effective to do ‘correctly’. Many business solutions also don’t have the lead time to do ‘correctly’. So the first truth is that these tactical or temporary solutions will always be required.

2) It is likely permanent

So if the tactical solution is required, what can we do about it? Well, first don’t believe the promise that it is a temporary solution.

Typically temporary solutions are created for items of smaller business value. If there were more value, there probably would be a reason to develop a better solution. So why would the business invest in a larger ‘correct’ solution when a smaller, tactical solution delivers the expected value? The answer if of course, that they won’t. There is a good chance that if the tactical solution is ever replaced it will be replaced with just another tactical solution.

So What Are We To Do?

So these temporary solutions will always be required and it is unlikely that a temporary solution will get redone ‘correctly’. So what are Software Development professionals to do?

The best we can do as Software Development professionals is to go in with our eyes wide open. Understand that the solution stands a pretty good chance of being permanent. Then try to design the solution as good as possible within the constraints. Don’t totally resign yourself to bad practices. Insist on small pieces of value that return great benefit if the solution needs to be maintained for years. Make the solution as data driven, parameter-based, highly cohesive and loosely coupled as you can. Don’t build in extra functionality but build the functionality so it is easy to adapt to future changes.

Also understand that not every business problem needs or deserves a perfect solution. Some solutions that are not robust may be the ideal solution for the problem at hand. We don’t always need to create a perfect solution. The solution should be just enough to deliver the required business value. I believe that as Software Development professionals we frequently forget that.

If we do these things we will find our lives easier as we try to maintain these solutions. We will also build confidence with the business as we are able to adapt to some future changes with these temporary solutions. It also is a good reminder that not all business problems deserve a strategic solution. The solution should just fit the business problem.

Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.