As the owner of a custom software 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.
1. No Error Messages: 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. 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 API.
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. This simple act of invalidating temporary passcodes is Coding 101 and should not have been missed.
3. Security Vulnerability: 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 and Logic: 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 organizing 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 less than 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 problems can also be very difficult. It’s much easier to start with well-organized code in the first place.
5. 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. 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 field workers entered. This client came to us losing customers because bad code made it look like they weren’t doing their work.
How to Make Sure this Doesn’t Happen to You
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.
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.
Quality Control: We have a list of coding requirements that all our developers must follow. We also employ someone specifically to test our apps repeatedly throughout the entire development cycle. Think of her 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 bug finder.
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.
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. We learned this one the hard way when a developer included a third party library that bugged an entire project. We put this standard in place so it would never happen again.
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 long-term maintenance as well.
Before investing time and money into an app that might not work, or worse creates significant problems for your business, interview mobile app developers 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.