There’s a lot of bad code out there. And it’s causing major problems for companies that are looking to build a more mobile-centric, transformational architecture.
Specifically, bad code causes projects to take more time, more money and more resources (aka Software Crisis) — which is repeated over and over and over unless a company revisits and updates the long-standing practices it has adopted.
But it starts with the culture — and there is some serious clashing taking place.
When I started my career in digital, large groups of people were writing code for no sake. And nothing was human-centered. But everyone else — including those who were building the products — was taking a customer-centered approach to development. This has led to a clash in corporate culture today.
A Culture Of Unacceptable Code
In large part, unacceptable code has come about because companies are rushing to market too quickly and engineering is de-coupled from the true end goal of satisfying users. It is a systematic issue, even though many think the solution lies in putting cross-functional teams in charge of product delivery. Typically, you’ll find your developers wasting time on CRUD operations and other no-value plumbing activities.
Mitigating the coding problems takes proactivity: keeping code current and slowly debugging or paying off the existing “bad code” technical debt. This also means biting off only what you can chew in app development — and spending time on customer-valued features.
Getting Rid Of Bad Code Smells
“Code smells” — a common term in the developer world — are hints that something has gone wrong somewhere in the code. Usually, it’s a symptom that indicates a deeper problem, pointing out weaknesses in design that may be hampering development or even increasing risk of failure. Here’s a look at how to mitigate (or eliminate) bad code smells, from both a technical and process standpoint:
- Refactoring. From a technical perspective, it’s important to put a new architecture in place without breaking existing systems. Refactoring is a great way to do this, which is why it should be part of your base processes. It’s not possible to predict everything in the future, so refactoring allows engineers to be in a “ready for action” mode. It also makes the existing code a bit more nimble and more prepared for the next wave of the future. Implicit in refactoring is added cost; however, this is traditionally where things break down.
- Bringing In The Right People. From a process perspective, you need to stop bad code from being written. But, with (often) many developers on your team and many split across other projects, how do you assess how they are doing, particularly when you bring on new team members? Implementing a process for careful reviews of code is important — and a failure to do so further spreads bad code smells. One of the best ways to mitigate future issues is mentorship. This means assigning experts to review the craftsmanship of other team members, coach them on best practices and encourage the meticulous use of tools. Without this process, you’ll always have bad code somewhere.
- Test-Driven Development. To enable refactoring, you can only do so if you can prove that your solution functions before and after the refactor. This means you need to test coverage at all times. If you lead with tests, then you immediately turn on the ability to refactor as you learn more from your users about needed features.
Eliminating bad code smells requires a new mindset. In today’s enterprise, product managers have a lot of power and a composite of responsibilities. The fast pace of work requires small iterations and continuous deployment, while supplying a high-quality product. Being capable of delivering at that speed means you need a cross-functional team whose mindset has shifted: their goal is delivering for their customer.
The Future: Less code
As software turns into functions (i.e., “if this, then that”) and innovation in IoT explodes, less code is actually being written. Single-function applications are becoming more common: apps that have very little code but are valuable and able to do more. Shockingly, there hasn’t been a whole lot written on this topic, but I suspect in the future a person with an idea might not have to go through a software engineer to turn it into a functional product.
Until then, the path to mobile transformation is littered with bad code. For companies both large and small, projects will consume resources — until bad code practices are eliminated.