Bugs happen: 4 bugs to expect when developing a Salesforce app
10 years ago we were introduced to an operating system that would change our lives. In 2007, Apple introduced the iPhone and its game-changing mobile operating system, iOS. But as of last month, they are still finding bugs on the release day of the newest version. So if the world’s largest tech company can’t build bug-free software- why would anyone expect app development consultants to?
Now, we’re not saying that bug-free software can’t be achieved. It technically can. But why would anyone want that? It’s just not economically viable to have bug-free software unless you’re building an application that’s life-threatening.
Why you ask?
Well, just read what David Heinemeier Hansson, the creator of the popular Ruby on Rails and founder of Basecamp, had to say about bug-free software:
“While no one likes bugs, far fewer people like the alternative: feature-less software. How do you think the market would receive the iPhone 7 if its headline improvement was cutting 1/3 of the features to shrink the code base so it'd have fewer bugs?"
So why do we need bugs? Well, let’s start with what a bug really is.
What is a bug?
A bug is a conflict in logic within a particular solution. Typically it is a result of a coding that may not recognize certain variables within a deployment. A bug can affect the outputs of the solution but is generally only within a particular use case and does not inhibit the user from using the solution.
It is important to note that bugs are often related to multiple variables and in most cases, the solution, consultant, and client have some responsibility.
However, a bug is not a missing feature. Often, we expect a feature to be present that isn’t there. And, sometimes, this is confused with a bug when the software doesn’t work the way we want it to. A missing feature is different than a bug.
Four types of bugs
There are four categories of bugs and each of them should be managed differently. Of the four bug categories, only the first can be vetted prior to deployment by your consultant and the rest will likely occur after launch.
Architecture Logic Bug
What is it? The solution architecture logic bug is a failure in the system or a logic that is unresolved. This happens when there is a conflict of logic that is prohibiting the functionality to produce the intended outcome. In this case, the issue lies within one system.
How do you know? This is typical when you are expecting something to work within the user story parameters and it doesn't. It’s key to note here, this bug occurs most when there is only one system or solution involved in the issue.
How do you resolve it? Submit a support ticket detailing the use case to your consulting partner for review. Provide a real example with the actual outcome as well as the intended outcome.
Who is responsible for the fix? In this case, it is typically a fix for the consultant that has been tasked with configuring the solution. However, this can be difficult to discern. Ultimately, a diagnostic will likely have to occur.
Use Case Bug
What is it? The use case bug happens when logic is unresolved due to an undiscovered use case.This happens when a use case that represents 5% or less of the user experience was discovered after the deployment. In this instance, neither the consultant nor the client could have predicted this bug since the use case scenario was not recognized as a base concern and thereby unwarranted of a user story during the needs assessment portion of the project.
How do you know? This is typical when a use case has revealed itself that was not vetted while collecting user stories. This is usually found when you have an integration with another solution.
How do you resolve it? Submit a support ticket detailing the use case to your consulting partner for review. Provide a real example with the actual outcome as well as the intended outcome.
Who is responsible for the fix? In this case, the responsibility is on the client for not clarifying the use case to the consultant during the needs assessment portion of the project. However, this can be difficult to discern. Ultimately, an assessment of the use case and a diagnostic will likely have to occur.
Configuration Change Bug
What is it? Much like the integration bug, this happens when there’s a conflict between two different solutions. This is usually related to a conflict in the architecture that has occurred after an update to one of the said solutions. This type of integration bug usually starts with an issue from the application (i.e. third-party app) connecting to the hub solution (i.e. Salesforce) or a configuration change in the hub solution by the client or the consultant.
It is typically understood that it is the responsibility of the application to ensure their app is connecting appropriately with updates. However, extensive customization of a hub solution can make the potential conflict infinite.
How do you know? This usually happens after a recent update by one of the integrated solutions.
How do you resolve it? Submit a support ticket detailing the use case to your consulting partner for review. Provide a real example with the actual outcome as well as the intended outcome. With this bug, a full diagnostic will be needed across both solutions.
Who is responsible for the fix? This is arguably one of the most difficult bugs to vet since multiple parties may be involved. In this case, it could be third party app for not notifying the client of the update or either the client or consultant for changing the configuration without consideration to the integration mapping. However, this can be difficult to discern. Ultimately, a diagnostic will likely have to occur.
Integration Bug
What is it? The integration bug is due to a conflict between the architecture of two disparate solutions, such as a CRM with a website’s content management system (CMS).
How do you know? This is typical when you are expecting something to work within the user story parameters and it doesn't. This is typically found when you have an integration with another solution.
How do you resolve it? Submit a support ticket detailing the use case to your consulting partner for review. Provide a real example with the actual outcome as well as the intended outcome. With this bug, a full diagnostic will be needed across both solutions.
Who is responsible for the fix? In this case, it is typically the job of the consultant that has been tasked with configuring the solution to fix. However, this can be difficult to discern. Ultimately, a diagnostic will likely have to occur.
What you can do moving forward
You’ll want to keep an eye on your typical use cases and ensure those are bug-free. Making sure the needs of your main use cases are met should be a priority for ensuring a successful project. But remember, the more use cases you incorporate the more buggy a project can get.
You should also continue to document any questions, new use cases, or bugs you may find. Consider when to hold your consulting partner accountable versus the solution. Many times we find it’s a solution limitation that causes bugs. Bring your findings up regularly to your consulting partner to maintain a strong working partnership.
And finally, no one needs to be added to the project. Adding more developers to hunt down bugs doesn't really solve the problem. If anything, more developers will increase the odds of more bugs. This is why Amazon CEO Jeff Bezos insists on the "two-pizza rule", a rule that states if the team requires more than two pizzas to feed it, it's too big. Continue to have open and honest conversations with your consulting partner to discover new use cases or issues. This will be much more helpful than adding anyone to the team.
Remember, the end goal is to write software that is easy to use and maintain
We’re not saying the end goal cannot be achieved by pushing for bug-free software, but it’s going to make the project timeline much longer and add copious amounts of unnecessary stress. So keep in mind- bugs happen! A good consulting partner will not only try to achieve easy to use software but also help you through this process when a bug does occur.
Have you been thinking about developing a Salesforce app? Do you want to see what an experienced team can for you? We’re here to help. We’ll walk you through development to launch, and even help you plan a sustainable marketing strategy for your Salesforce app. Ready? Let’s get started.
