Quality Code: Codebase Fragmentation
Quality Code: Codebase Fragmentation
I have wrestled with Codebase Fragmentation since I first became a web developer. Typically, web developers at an agency handle multiple projects. In addition to the projects themselves - bug fixes, new projects, platform updates, documentation, and new techniques take up our days. Codebase fragmentation occurs when your projects are updated unevenly. New projects get the latest techniques and updates, it is very natural. Rarely do we have the time to go back and work on projects that are finished!
Codebase Fragmentation is an Issue
Codebase fragmentation is indicative of a lacking quality assurance process in the development team (or perhaps worse - no leadership in general.) Regardless of the security issues from un-updated code, having multiple versions of how you do things, or projects that have fallen into disrepair can have a number of nasty side-effects. First of all, new work or updates to old projects take longer (which means they cost more.) It makes it much more difficult for a developer to understand the product if there are 3-5 different versions of how the product was built. Building and updating projects with junior developers becomes difficult to impossible. Secondly, one for the bottom line guys - it becomes difficult to impossible to retain clients. Sure if you only have 3 projects to worry about you’re fine, but the moment you start talking 50+, it almost becomes easier to churn clients than to retain clients (looking at you - every web design company ever.) It doesn’t take a business genius to know that keeping your clients is easier than constantly finding new ones. Thirdly, software breaks. If you don’t manage your codebase as a whole - chances are you have issues in several different places. Web companies that focus on the design generally do not have the technical expertise to even be aware of these issues, nevermind have the technical leadership required to champion these issues to management.
Managing Your Codebase (Using GIT)
As always, let’s start small when we implement new policies to make things better in the long term. If you don’t use version control, well - you aren’t ready for this yet. Start smaller and build your QA process gradually. Anyways, we use GIT but I’m sure the other offers have some form of what I am about to describe. We have a blank project called “BOILERPLATE.” Any update, upgrade, or new techniques get implemented here first. From there, we attach BOILERPLATE to all of our projects as a remote repository. We merge the changes into the individual projects on a regular basis. Before we started using this technique, an upgrade took days to make sure everything was right - this now takes less than an hour (there are also several other QA processes that make this happen, but merging the code itself is quick and easy.) We have a single project to place all new platform-wide techniques and initiatives.
Codebase Quality is a Management Issue
QA and managing a large codebase is not easy. It is quite difficult and takes a lot of time and knowledge to get things to a point where clients expect them (clients, and users in general have become used to/or expect things simply working perfectly.) While management might not expect to think about the codebase, it is very much a management concern. Often we are concerned with the immediate cost, but a good codebase allows developers to iterate faster and with higher confidence in the quality of the code. Especially when we find ourselves asking developers to recycle old code to save time and money on new projects, the codebase becomes more of an investment than we might typically realize.
Tap or click on these posts to navigate to the next or previous posts.
This post is part of a larger series. Tap or click on a post to view more in this series.
