Something’s wrong at your company.
Your customer support team is struggling with an uptick in calls caused by difficulties customers are having with your website or app. Your sales team is frustrated by continually crashing digital demos. Your marketers are anxious because that they can’t make changes to your custom software as often as they’d like. If you’re receiving complaints from customers and departments across the organization, it may be time to look under the proverbial hood. Pervasive complaints, problems, and frustrations might have a common root cause: fragile, buggy code that’s creating issues for your company’s custom software—i.e., your website, apps, and other proprietary software—and are wreaking havoc on your business. If you’re not working with it intimately on a daily basis, you may not immediately realize that the root of these disparate complaints could be the code that underlies your company’s custom software. Often, code issues are the result of a sub-par development process—which means your engineering team might be working harder than necessary and making the same unwitting mistakes over and over again. Telltale signs of subpar software exist, even to a relatively untrained eye. Read on for 10 ways to tell if your code is in trouble—and learn what you can do to fix it.
1. You’re too often over deadline and over budget on your software development projects
To be sure, multiple factors can cause your teams to miss deadlines and exceed budgets. In the engineering department, though, faulty code can necessitate costly, time-intensive work for your engineers. If your team members constantly need to put in long hours fixing finicky applications thanks to problematic code, you may find that your personnel costs are higher because every small change requires copious attention and time—and that’s just not sustainable for your long-term budget and plans. If you’re noticing a pattern of delays and ballooning budgets, problematic code underlying your custom software might be at the root of your problem.
GNAR GNUGGET: At Gnar, we deliver guaranteed bug-free code within the first week. How do we do it? By applying our Quality Software, Faster. ™ process to every project, which keeps our engineers moving toward your deadlines while ensuring high-quality code. When you have a clear, well-documented software development process in place, staying on time and on budget isn’t just doable—it’s habitual.
2. Your customer service center is inundated with calls
Have your sales and customer service teams received an uptick in complaints about your application? Are you service centers flooded with calls and tickets related to your customer-facing software? If you’re constantly receiving complaints about multiple aspects of your site or application, that’s a telltale sign that something more foundational may be amiss.
GNAR GNUGGET: Don’t write off customer calls as problems for the support team alone. Treat each complaint as a clue and keep on the alert for issues that could point to a deeper problem with your software product.
3. Your application or site doesn’t perform well
In addition to your customer service teams—who will certainly let you know when customers are reporting a sub-optimal experience with your site or application—it’s likely your internal teams will notice (and complain) that your app or site just isn’t performing well. When software is coded inefficiently, all stakeholders who interact with it will notice a number of frustrations. For example: Does your site or application crash frequently? Do pages take a long time to load? Does certain functionality, like search, take forever or simply not work? Does your site have a poor Google Lighthouse (a common performance metric) score? Each of these issues could be harbingers of a deeper problem with your code.
GNAR GNUGGET: Don’t sleep on seemingly small problems, as they could have long-term costly implications for your business. A poor Google Lighthouse score, for example, directly impacts users and your organic search results—and can lead to reduced visibility from prospective customers.
4. Making changes takes too long
If you’ve stopped asking your development team to make seemingly minor changes—even something as simple as changing text or an image—to your website or other applications because those changes take weeks to implement, you may have an underlying problem with your software’s code. The inability to make timely minor changes can have a range of reasons: the code could have been built in a fragile manner, or it could have been built in such a way that makes it difficult for current team members to read the code and make changes. “It’s often because of mounting tech debt: that is, when you rush to deliver product without ensuring stable code,” says Gnar co-founder Mike Stone. “If the code that runs the application has historically not been written in a way that’s scalable and extensible, you’ll eventually get to a point where adding new changes takes a really long time which then adds to the overall cost.” And those delays can have a domino effect across the company. If you’re noticing that the pace of innovation in your organization has slowed, that could be a sign of software trouble.
GNAR GNUGGET: Writing solid, test-driven code in the first place is key. But it’s equally important to enact a culture of clear documentation in your organization, so future team members understand—and can more easily react to—the decisions prior engineers have made.
5. You can’t update your application or website fast enough to get users the improvements and information they need
Does this sound like you? You or other company leaders have an idea for a new feature or features that should be added to an application, which could significantly improve the user experience. It takes so long to release a new version of the software, though, that by the time users can take advantage of the new feature(s), you have a whole new queue of enhancements you’d like to release. If your development team is releasing new versions of your app very infrequently, that could be a signal that your software is in trouble. As a general rule of thumb, more frequent deployment points to healthier software—and a better experience for your users, who benefit from necessary improvements and updates more quickly. Less frequent deployment could detract from the overall customer experience, as even small changes that don’t take very long to code could take a long time to reach users’ hands.
GNAR GNUGGET: At Gnar, Continuous Deployment is an integral part of our Quality Software, Faster.™ process. As part of this process, we verify code by an automated build that runs automated tests to identify any issues before deployment, so we can help clients release updates ASAP.
6. Making even small changes to one feature breaks another feature
Is your team frustrated by exceedingly fragile code? Does a small tweak to one part of your application create a domino effect of problems in other, seemingly unrelated, areas? If so, faulty code could ultimately be to blame. This is not just frustrating for your engineers—it’s problematic for your company’s value proposition and bottom line, as making necessary changes to a fragile codebase could result in a long and protracted testing phase.
GNAR GNUGGET: To avoid the negative ramifications of fragile code, it’s essential to bake robust testing into your overarching software development process. At Gnar, for example, our Quality Software, Faster. process includes multiple testing steps, so we can rest assured that future changes to one feature won’t cause problems to others.
7. Your process requires lots of manual, expensive Quality Assurance (QA)
QA—any QA—is good. It ensures your company is deploying the highest-quality versions of software possible. But if your process is heavily manual with little automated QA, that can indicate an overarching problem. Automated QA enforces consistency and comprehensiveness in testing. What’s more, automated QA more quickly and easily identifies problems, which allows your team to course-correct more quickly. The lack of expedient QA can lead to mounting tech debt, a higher likelihood of regressions as new code is added, and other related issues.
GNAR GNUGGET: At Gnar, we automate QA as much as possible via our test-driven development process. That way, we know immediately if new features will break any existing features. Test-driven development provides an automated test harness around the application and precludes deployment until all those necessary tests have been passed.
8. One person is critical to your technical process
Companies with healthy, well-documented code don’t have a single person on whom every technical process hinges. Is there one person on your development team who’s critical for every code fix, feature change, or new deployment? Does the velocity of the development team’s process stall noticeably when this person is absent? If so, that’s problematic. Your application should be accompanied by excellent documentation, which allows multiple engineers to handle any problems that arise and make changes as necessary. When too much information lives within a single team member’s brain, your system simply isn’t scalable.
GNAR GNUGGET: At Gnar, we maintain a (somewhat macabre) metric we call the Bus Count. That is: the number of people on the engineering team who can get hit by a bus before the software is in true trouble. If your bus count is just one, then you’re putting too much pressure on a single person—and potentially causing cracks in your software’s foundation.
9. You’re having trouble recruiting engineers
Is your engineering team spread too thin, but you’re having trouble recruiting new team members? If you’re extending multiple offers that developers ultimately don’t accept, and/or if you find existing team members continue to resign, these are signs of trouble. That’s because in general, the less organized and the higher the tech debt a codebase has, the more difficult it is to recruit and retain engineers who are willing to work with it. Even if your engineers don’t expressly articulate an overarching code problem with their voices, they’ll do so with their feet.
GNAR GNUGGET: Software engineers want to spend their time developing new code and refactoring existing code to make it better, not chasing down regressions or bugs because of poor documentation and lack of integrated testing. These investments save your engineers’ time and frustration.
10. New functionality doesn’t work as intended
Has it happened that you’ve launched a new feature or functionality and it just…doesn’t quite work as you’d expected? An underlying code problem does not have to result in a bug, per se—it could simply lead to a feature that doesn’t work the way you wanted it to. If the engineer building the feature didn’t understand the requirements, or if those requirements weren’t documented well, or if they weren’t thought through comprehensively, you may find your team struggling to create software that works the way you intended.
GNAR GNUGGET: One way to ensure your features perform as intended every time? Make sure your engineers spend time iterating on design before development begins, and that they create solid user stories to ensure alignment.
Does this sound like you?
Each of the above issues is symptomatic of a custom software code base with significant tech debt. The price of delaying a code audit and making necessary software and process improvements can be astronomical, as many of these symptoms can frustrate customers, staff, and investors; reduce trust in your brand; and contribute to costly delays and bugs. To fix your software, improve your process, reduce your costs, and keep your engineering team happy, you must first diagnose the root causes and issues associated with that tech debt and implement a repeatable, agile process that prevents their arising in the future.
We can help
At Gnar, we thrive on helping clients solve their gnarliest software problems. We’ve worked with multiple clients who have struggled with problematic software and development processes, and our successful experiences enable us to identify problems and design long-term solutions. For example, our client First Line Technologies had worked with another development company to create a mobile app. That company had essentially repurposed old code without any testing infrastructure, which precluded the company from making changes easily and resulted in a poor experience for app users. Before they hired us, First Line noticed several signs that pointed to problems within the existing app’s code. The Fist Line team found it difficult to make changes—including seemingly small changes—to the app. Because there was no testing infrastructure, the team lived with the constant threat that making even a small change could break an important feature. Additionally, the mobile app’s registration function didn’t connect to First Line’s CRM, which resulted in lost sales opportunities. Finally, the user experience with the legacy app was not ideal, but the team had no real way to improve that experience. First Line wanted to expand the mobile app’s content, but doing so with the existing code was virtually impossible. When we were hired to enhance the app, we conducted an extensive code audit before commencing any work. We learned that almost all new features, when implemented, broke something else. We communicated to the client that the codebase needed to be rebuilt, because otherwise building new features would take much longer and be much more expensive. In consultation with the client, we determined that the cost of rebuilding the WordPress back-end was too high relative to its benefit. While WordPress is a somewhat unusual back-end choice for a mobile app, there were several benefits to its use at Front Line: the team was already using that system for its web app, and it was important to them that they could seamlessly add and update content on both the web and the mobile apps. We knew switching to a different back-end system could be prohibitively expensive, and we were confident in our ability to build a new front-end using the backend that was already in place. We were able to salvage the app’s existing backend while creating a fresh, easy-to-update front-end built with clean code. In fixing First Line’s fundamental problems, we set the team up for continued success. Now, updates take just five minutes, because the overall goal is clear, the process is documented, QA is automated, and test-driven development and continuous deployment leave engineers confident that any changes they make will not break existing functionality.
When you work with The Gnar, you’ll benefit from:
- An exemplary team of US-based software engineers who are 100% dedicated to your project
- A Bug-Free Warranty: we’ll repair any nonconforming, released code at no charge for a full year
- Our agile development process that balances quality and speed and enables us to deliver code within the first week
- A Temporary by Design staffing approach that fosters self-sufficiency
- A tool-agnostic mindset to meet your specific vision and needs
Don’t settle for sub-par software
If you believe your company may be struggling with sub-par software, struggle no longer. Contact us today for a free code audit or to discuss how we can help you get back on track.