Let me tell you a story
I’m sure you have heard a similar story, or even lived something like it.
Your team inherits a software project that wasn’t fully completed but is still expected to be delivered. It is mostly done, with just a handful of missing features. You have some great talent on your team, including veterans who have delivered enterprise software for fortune 100 companies. You have confidence that your team will easily be able to complete the project in a few weeks.
The team starts working on the code. The first week seems just like normal — the team is cranking away through the code, learning their way around, identifying where the changes need to be made. You get to the end of the week and nothing has been delivered yet, but you are sure that it is just due to the fact that they are still getting over the hump of adopting the code as their own.
Two weeks later, the mood has started to shift. Folks have become less confident, the cheerful enthusiasm that was there at the start has ebbed away. You start hearing gripes about how the project needs refactoring or just to be thrown out and replaced. The business is getting frustrated with the delays, and features that were working have started breaking as the team starts delivering the remaining features.
Eventually your team delivers the final product, but it is buggy and the team is just glad to be done with it and move on to other things. When bugs are reported, the team takes them on, but no one feels proud of the work that they have done. The business doesn’t trust the team when they say that they could have done this better. Some of the best talent leaves the team for greener pastures.
Of course it does. I would like to believe that this is a rare occurrence and that most software projects are successful collaborations that bring great joy to the teams that worked on them. Unfortunately, that isn’t the case. This happens quite often. Switching from waterfall to agile hasn’t fixed it. Moving to TDD didn’t fix it. Hiring better talent didn’t fix it. What is going wrong?
Far too often, the reason this happens is that teams aren’t tracking code quality and technical debt. When the projects start off, everything is happening fast and smoothly and it doesn’t even seem like quality monitoring tools and tracking technical debt even adds value. Only when the project gets beyond a certain size does it become clear that something was missed.
Software development used to be a field that was highly specialized and required lots of training and experience to do correctly. Over time, advancements in code editors and easier languages have lowered the bar and allowed folks even without technical backgrounds to join in and write software. This is not a bad thing, but it does create an illusion that writing great software is easy.
Writing good code is extremely hard. Even seasoned developers who have been writing code for years can sometimes struggle to write code that will not only deliver what is needed but will also be easy to maintain and adapt to changing requirements. Sometimes the business changes direction, and a bunch of code suddenly becomes irrelevant or requires modification. The best developers anticipate these conditions and plan ahead for it. That doesn’t mean it always works out.
With the workforce expanding faster than it can be populated with experienced talent, a lot of companies are being forced to be more lenient on hiring, brining on younger talent and hoping they will mature on the job. This isn’t a pipe dream — there are so many online resources for learning skills and researching answers that a lot of those younger developers are managing to get by. They also tend to be cheaper than seasoned developers, so it seems like a reasonable tradeoff.
The result of this has been a large increase in the amount of bad code. Code that is more complex, harder to maintain, and less adaptable to change. Companies used to write code that ran for decades, but now code is often replaced within a few years. A lot of ambitious projects end up derailing and never see the light of day. A lot of veteran developers end up on short stints, moving around from job to job instead of sticking around.
So How Do I Fix This?
Fortunately, with security becoming more of a daily concern, attention to code quality has picked up. Not as much as I would like, however, and there are still companies being hacked who clearly knew there were issues but didn’t prioritize them appropriately. The safety and security of the customer data just isn’t as important as delivering features on time.
What needs to happen is to shift more attention to quality and away from quantity. You want your customers to be able to do great things soon, but if they start trying to do those things and they see defects, it ultimately has a negative impact on your business. Obviously writing perfect software is not really realistic, but you should aspire to write high quality software because ultimately that is a huge part of the products and services you deliver.
There is even a way to get both high quality and fast delivery. Containers and Serverless have become an important part of software development lately by allowing developers to deliver smaller and simpler units of functionality. These smaller units of functionality are easier to build, test, and deploy. They also scale better and faster.
You will need metrics on the quality to ensure that standards are being maintained. It is far too easy to let little things slip from time to time, similar to how you might avoid cleaning your room every day and end up with a mess you just don’t want to deal with. When you have tools like Sonarqube checking your code and pointing out areas that need to be addressed, you will catch issues much earlier on when they are still manageable. The checks aren’t just for defects — it will also check for security vulnerabilities as well.
You will need to invest in training your team to write better code. Make use of sites like Pluralsight that not only teach them skills, but also help them to evaluate and gauge where the gaps are so that they can continue to improve over time. Even senior developers need to continue learning to keep on top of changing languages and toolsets to maintain their edge. Learning days (stopping work one day a month to learn or refine skills) are a big help with this.
Code needs to be something that isn’t just written and forgotten. It needs to be owned. It needs to be cherished. The quality of that code should be as important to the business as the quality of the user experience. The more you build code that lasts and is reusable, the less time you will spend fixing bugs and refactoring.
Learn to make use of technologies that make software development easier, like Containers and Serverless. Companies that have adopted these methods have gone from delivering software every few months to delivering software many times a day. I’ve been told that new hires at MetLife are able to write code that goes into production the day they start working at the company. To me, that’s awesome.
In this article, I talked about a big issue in the software development world, one that I care about a lot — software quality. I talked about how trying to pick up bad code and make it better often leads to software project failures and team breakdowns. Instead, teams should be focusing on not writing bad code in the first place. There are a multitude of tools that are making it easier to ensure code is high quality, and methodologies like Containers and Serverless can allow you to deliver smaller, simpler functionality faster. Training the team is a critical part and should be actively encouraged. Most of all, don’t just fix bad code; stop writing it altogether.