As the owner of a custom software design and development company, I can tell you that poorly written, shoddy code is more common than you might think.
There is an assumption floating around that if a company or developer provides app development services, they must be good at it. And, that coding is easy and requires minimal training and experience to do well.
This is not the case, and I’ve witnessed it first-hand when clients hire us to fix software that isn’t working.
We’ve had some jaw-dropping moments here at Big Fish, while digging through source code that’s not our own. I’ll tell you about some of them in this article.
You see, poorly written code is more than a minor annoyance. You can lose customers when your software doesn’t work as it should, or find your company in the headlines for a major security breach.
Quality should be expected, but it’s not something you can blindly count on.
Here are six situations we’ve encountered at Big Fish where a company approached us to fix their existing app.
Software Problems Encountered by Bad Code
1. There Are No Error Messages in Bad Code
One client employed a well-known software development firm to create their app, only to have it never work properly. They kept telling the developer it wasn’t working, and the developer said it was user error.
When we dug into the source code, we were shocked. Among other things, error handling (aka error messages) was not set up in the app.
So, when users would try to create their account, if their password wasn’t long enough or they’d chosen a username that wasn’t available, they had no idea. Nothing in the app told them that their account wasn’t getting created and why. It just looked like they later couldn’t log in.
2. Coding Errors Include Not Invalidating Temporary Passwords
One app, created by an app development company here in Florida, came to us with a real security issue: All the user accounts created for the app were given the same temporary password. That password was the company’s name, and it was hard-coded in the software.
When users changed their password, that old, company name password was not invalidated. Anyone could log into any account using it. Meaning, once you knew the “temporary password” you had access to every user account in their system. The simple act of invalidating temporary passwords is Coding 101 and should not have been missed.
3. Bad Code Can Cause Security Issues
One enterprise-level app came to us completely vulnerable to outside hacking. This app was open to injection attacks as none of the database calls were written properly or happening over a secure connection. This gave any savvy hacker an opening to introduce (or inject) malicious SQL code…for example, to gain access to their database and view, modify or delete their private customer data.
Our client was unaware of this potentially catastrophic issue in their code. We found it (and fixed it!) while performing software updates for them.
4. Poor Architecture Causes Software Problems
An app is not just an app in isolation. Anything more than a simple calculator is bound to be part of a larger software system that includes multiple APIs, databases and web applications. Your app itself has thousands of lines of code. There is a strategy to organize all of this, and if it’s not thought out or done using best practices, you will have a mess on your hands.
Adding new features, or fixing bugs, can be like looking through a jumble of electrical wires to figure out why a light switch won’t turn on. Something that should take under an hour, could take many hours or days if your original developer or team did not create a logical structure for your app.
Finding the source of software problems can also be very difficult. It’s much easier to start with well-organized code in the first place that is not riddled with coding errors.
5. Bad Code Consists of Not Using Comments or Helpful Naming Conventions
Speaking of disorganized code, quality code should use consistent naming conventions and comments.
Just as with any employee, if something happens to your developer or they leave the company, they should be setting up their work for the next person to easily take over. In a team environment the same applies.
Companies have hired us to fix their code, and we’ve found it full of nonsensical variables, functions and classes and little to no comments. Deciphering this makes our job much more difficult and time consuming; you don’t want that.
6. Software Issues Cause General Instability
One of our clients came to us with a field service app that they used to demonstrate to their customers that work was done. The field service techs would log their work, the time it took, and take photos so customers could verify what they’d been charged for.
Sometimes, the app simply wouldn’t save the data that field workers entered. This client came to us losing customers because bad code made it look like they weren’t doing their work.
Solutions for Bad Code and Software Issues
At Big Fish, we have documented systems and processes in place to ensure that we create quality software for our clients. If you can’t check the code yourself, checking against some of these standards can help ensure that your mobile app is built to high standards.
1. Experienced Developers
No one on our development team has fewer than five years of software development experience, and we never outsource our code. Asking about just these two elements can give you hints upfront about an agency’s coding quality. If junior developers will be writing your code, you need to be all the more confident that what they create is closely supervised by a more experienced team.
2. Quality Control
We have a list of coding requirements that all our developers must follow to avoid coding errors. We also employ someone specifically to test our apps repeatedly throughout the entire development cycle. Think of this person like a coding editor: It’s hard for any writer to edit themselves, because they read what they meant, not what they wrote. Our internal quality assurance processes mean our clients and their customers don’t have to play the role of finding software problems.
3. Enterprise-Level Experience
Over the years of hiring software developers, I’ve noted that not all experience is created equal. A seasoned developer, who has worked as part of a team on large complex software systems, will have knowledge that you don’t get in school, or by developing simple applications. These lessons-learned and best practices are invaluable to our clients when they hire us to build their mission-critical software.
4. Open Source Standards
Before our developers can use open source or third-party libraries in a project, every other developer on the project (as well as the project manager) approves it. This ensures that these choices are made carefully and only quality, well-supported libraries are used in our code to avoid potential software problems. We learned this one the hard way when a developer included a third-party library that bugged an entire project. We removed the library and put this standard in place so that would never happen again.
5. Commenting and Naming Conventions
Our Big Fish Coding Standards require that our developers use descriptive names for their functions and variables, and include comments in their code. After all, someone else may need to decipher their work in the future and we want to make it easier.
Quality code matters. Not just in the short-term initial development of your app, but for the sake of the long-term cost of maintaining the app as well.
Prevent Software Problems & Coding Errors with Big Fish
Before investing time and money into an app that might not work, or worse creates significant problems for your business, interview mobile app design and development companies with respect to the standards above.
It’s not necessary for you to be able to read code to ensure that your mobile app is built to high-quality, if you think and ask about some of these standards from the outset. Contact us today to learn more about how Big Fish can help your company.
