“If You Wait for Perfect Conditions You Will Never Get Anything Done”

— Ecclesiastes 11:4

 

Software is highly complex.  Being able to handle every single possible use case is virtually impossible.  Even testing can never be done across all possible paths (which may number in the millions and tens of millions of possible combinations).  Software is now also highly componentized, with software depending on each other’s code that was written and is maintained by others and in locations that may be across the globe cutting across entirely different languages, techniques, servers, and programming languages.

 

Bugs therefore, are an unfortunate reality for every software product.  Even the most rigorously tested software on the planet, such as the ones that operate medical devices or that control aviation and space systems have bugs.  Not surprisingly, enterprise and commercial application software will have bugs.   To complicate things further, the infrastructure software that applications may be built on top of also have bugs.  Operating systems, which these applications run on, have bugs as well.  Even the hardware on which the applications run on have bugs.  There are many points of failure in any interconnected system and these types of applications are notoriously complex.

 

Software applications also don’t have a perfect feature set nor a perfect UI.  There are always limitations in software because every customer’s needs are different and no software can perfectly address every customer’s needs.  Everyone needs to come in with the right expectations.  Technologists understand this inherently and good business leaders do as well.

 

Clearly, successful commercial applications are successful for a reason – the technology has to work.  What can’t be expected is that the software be perfect.  Things won’t always work the way you ideally want them to and sometimes there may be a bug or feature request that will get in the way.  What are some of the options available when you run into a roadblock?

 

The first thing to do is research what the issue is.  The forums and google searching in general is a great way to see if the issue has already been experienced.  Note that Salesforce itself is well documented and that the forums, success communities, and blogs are quite prolific with tips and issues.  Technical support is a great avenue as well to confirm.

 

Of course a workaround would be great to find.  Workarounds typically have tradeoffs – there may be a decrease in functionality or in usability so be prepared to potentially make some compromises.

 

If a workaround is unacceptable there are a few options to explore.  One is to log the issue on the Ideas exchange.  Salesforce product managers and staff monitor these in order to help them prioritize issues for development.  The more an idea is voted on, the more attention it gets.  Note that very rarely will an issue get immediate attention unless it is a true Priority 1 bug.  You have to have a lot of patience in these situations.  Salesforce has thousands of customers and millions of users and does its best to address as many issues as it cans to help as many of its customers as it can.

 

But do note, some great workarounds may not involve changing the product at all.  Savvy business leaders know that when faced with product constraints, reengineering the process can be the most effective way.  While it may be an extra step, it may be well worth it in order to defeat a roadblock and move the project forward.  Yes a process may not be perfectly elegant – this happens all of the time.

 

Some workarounds require very complex require writing code or making elaborate workflow rules.  These significant changes are rarely worth the effort because they are costly to build and most importantly, they are costly to maintain.  When you have an elaborate workaround, they often are “brittle” in nature, meaning that when assumptions change the workaround may break.  A slight change in the configuration or even a new release of Salesforce can break something somewhere else, even in completely unexpected areas.  Still, the business requirement, if strong enough, may outweigh the short and long-term costs.  The whole picture just needs to be considered.

 

The business manager needs to weigh the costs and benefits of the different options to address a bug or product limitation.  While they should always optimize and push to get the best they can, they also must manage the realities that software has bugs and has limitations.   Going for an unrealistic perfection can permanently damage a project.  Instead, focus on the business requirement – how can the overall business requirement be met.  Oftentimes there are many solutions to the same business problem that don’t always require code.  One must also remember that in technology, keeping things simple is almost always the best practice.