An awkward conversation for us all
This won't be a technical example and won't have any example code with it, it is simply a talk. A talk that I don't feel most people are willing to have in today's software development environment; in fact I find most people any higher then a senior engineer flat out refuses to even address most of the time.
Software Critical Mass.
Some of you most likely have heard of this and some not, so here is the definition of software critical mass as I see it.
Critical mass - A stage in the software life cycle when the source code grows too complicated to effectively manage without a complete rewrite. At the critical mass stage, fixing a bug introduces one or more new bugs that may or may not be related to the fix directly but was still inadvertently affected.
Impact Vs Cost
Before I get into how to identify your approach to critical mass I'd like to go over some of the cost and issues that come up when discussing it. I talk about critical mass where I am currently employed a fair amount due to the fact that the original software was built in a monolithic way and there are a lot of efforts going into moving it away from that. In those efforts however there is always the question of "Why do we need to redo what is already working.", as a developer that spends 40+ hours a week in the code base my mind and I am sure your mind races with ideas as to why and it all seems obvious. But to those that don't spend the time in that code base such as most managers and C levels, it's not obvious.
Now I am not necessarily bad mouthing the higher ups in various companies because the lack of understanding goes both ways. As a developer you don't always see a lot of the business impact that the stall in new features, updates, etc have on the customer base/revenue.
This brings us to Impact vs Cost.
Impact is what developers are normally after, and cost is what higher ups are normally worried about. The stance can be switched as well however. The developer is concerned with how much time they put into sorting through a messy code base, and the higher ups are after a meaningful impact.
Determining Impact
Impact now has two definitions for us :
- Director/C level impact - The direct result of a change relative to the user which may create a change in revenue numbers.
- Developer impact - The ease of developing in the code base to make the changes that can satisfy C level impact ultimately
This often is brought down to time and cost for what kind of change is proposed. While there is no perfect way to determine this it is often beneficial to determine some base line definitions for what kind of changes will be coming.
For developers/leads
As developers we often say that we would like just to rewrite an entire pieces of the software or even the entire thing without any type of qualifiers on it. This doesn't seem like a very reasonable thing to do from a sky level view of how things work even though it may be entirely the right thing to do code base wise.
Determining impact for developers should ultimately come down a few factors in my mind :
- Ease of modification
- I generally consider this to be a time based metric. It will take a experiments to get a time but it is worth it.
- Small spin up time
- Again this can be measured but generally only when you are bringing new people on or starting up a new project.
- Readability
- Developer comfort levels when making changes
While some of these are anecdotal they can still be quantified reasonably via simple things like surveys and simply asking for a score between 1 and 10 every once and a while. I feel these key things are what lead to faster more polished features that require less constant upkeep.
So when you say that you would like to rewrite something try to attach value not on what we as developers would like but what the end result would be and it's value to a C/Director level impact because at the end of the day it's not our call on what initiatives get focused on. Not what we like to hear, but just the way companies work.
For Directors/C levels
If you are a director/C level reading this, then welcome. If not, feel free to forward this on to yours whatever your intention. Lets talk about value and reason to a developer. The primary goal of a developer most of the time is to create a better code base and a better piece of software because that means something that is easier to turn into a service or product to sell ( if they aren't at least attempting to improve things to some degree that is a talk for later ).
Determining the impact of something your developers want to do for whatever reason can be difficult, and some times we aren't the best at communicating why. But it also isn't productive to either side to just ignore them when they come to you, maybe in an angry or ill temperament, and tell you that there is something that seriously needs to be addressed. for one that doesn't make much sense for you to ignore the person you hired to maintain the software and spends their entire work week in it. Two it is a sign that something is unhealthy in both the code base AND your developers base. Developers don't like working in an awful code base.
So impact. Evaluating impact should be a duel effort between you and your team(s), but at a core level a good developer impact should give you a good impact. Now sometimes things just don't line up and you can't let the developers go off and do whatever they want. You obviously can't just spend all your developers time making the code base pretty; but again they shouldn't be ignored.
However to avoid this critical mass issue a compromise must be made. Business value is directly correlated to team value and health which is tied to your code base. So when a developer comes to you and wants to rewrite something, don't just turn them down, attempt a compromise of extended time to work on a Jira ticket to clean things up which should mean less effort and time is required to modify that same feature in the future, which will translate to your own initiatives.
Or if you want to go a level deeper, ask what new functionality can come of these changes and how it will actually improve the code base and support future features. Through this you can then gain even more value for an initiative because the chances of what a developer would like to improve crossing into new planned features or changes is pretty likely.
Recognizing Critical Mass Approach
Culture
One sure fire way to recognize critical mass is the fact that most of the developers constantly complain about how things were written awful and it is no use trying to fix any of it. When that starts to crop up I would say once every two week basis you are on the door step of critical mass.
It is worth mentioning that some developers are just always out to say everything is awful but never really participate in fixing anything, it has become their work ritual. Those types in my view should be removed from most scenarios but we all know at least one. Why this isn't a real measurable thing it can be pretty easy to take 10 minutes of random peoples time every once and while to find out how they feel about the code base.
Work load and ticket branching
For a more quantifiable way to measure critical mass approach is through ticket tracking. Now as a developer I often find ticket tracking one of the most infuriating things to deal with, especially with complex system changes. But it does have a place; this is one of them. If it can be identified that often times a fix, that is indeed a fix and makes something work correctly, breaks something else and creates a work load for your team more then the work it took to make the fix: your code base is approaching that critical mass. It's this type of occurrence that I encourage managers, leads, etc to really look out for. This type of metric is pretty easy to track given tools such as Jira because you can see things like spring overflow ( assuming all your Jira flows work ).
Now the tickets spawning tickets ( Ticket Branching ) thing is common in most companies but it depends on the percentage of the time a ticket will generate more work then it took to close. Ticket branching as I've named it, should really be under a 1/5 ratio from my experience. Now depending on how big the team is and the product that can be adjusted, but I have been able to take that anywhere I've gone so far.
There are numerous ways to deal with this particular issue, but that list is simply to long to be gone over for every type of situation; this is simply a warning to make people aware of what to watch for.
Wrap up
It's been a lengthy and most likely painful read, I know. Company politics, C/Director levels, listening to developers, and attempting to quantify is a hard part of the job, one that I see ignored more times than not. I am sure there are plenty of opinions some agreeing and some not, and that is fine. This isn't a guide, to do list, or one stop shop for how to run anything; simply my own observations on how software companies are run these days.
When it comes right down to it, the fact is that higher ups need to come down, and devs need to come up for air so something can finally get agreed upon, explained, and defined for things to move forward. It's hard, and this type of thing isn't something most people would say they have time for, but maybe that is part of the problem.
Critical mass can kill software faster then almost anything I've seen; why don't we all work together to make it less of an issue?
I will leave you with questions to ask yourself depending on where you are in a company, give these a good hard thought and be honest; then maybe change a few things here and there to see if you can make a clearer line of communication regardless of the level you are at.
- C/Director level
- When was the last time you had a honest talk with a developer ( not a manager ) about the state of the code base?
- Developer
- When was the last time you gave a thought to the companies stock, online reviews, and the current market?