Can you translate code quality into business impact?
Posted by nephrenka@reddit | programming | View on Reddit | 24 comments
Posted by nephrenka@reddit | programming | View on Reddit | 24 comments
hippydipster@reddit
The article claims red code is worked on at a rate that's 9x slower than green code, and yellow code is unclear, but perhaps 4x slower. The article lacks details on the definition of green/yellow/red code, which makes the whole post useless, but let's ignore that.
Let's say you have a codebase that's red. It took 2 years to build. Clearly, at the very start of that 2 years, it was a green code base. Probably moved to yellow at some point, then to red. Ok, and the presumption is that it's possible for devs to build such a codebase and always keep it green.
Let's say the current codebase spent 3 months as green code before it became yellow for a year, then red for the final 9 months of work on it. If we convert these to theoretical "work units" (WU), where 1 WU = 1 month of work on red code, then the current codebase took 9 +212 + 93 total work units to create (we're simplifying yellow code as being 2x faster to work on than red). That's 9 months spent on red code, 12 months spent on yellow code, and 3 months spent on green code. Two years, 60 work units.
If the devs had kept the codebase green the whole time, it would have taken 7 months to do.
First observation: not one of us believes that.
Second observation: If all future work is going to take 9x longer than it could have taken, then if we throw away the codebase entirely, and rewrite as a green codebase, we will catch up to development in 8 months, because after 8 months of additional work, the team that continued working on the red codebase will have completely 8 more WUs, for a total of 68 work units in the app, and the green team, in 8 months, can do 72 WUs.
The obvious answer is that keeping a green codebase is a fantasy for almost all teams of developers, as they do not have that level of skill.
kuraianlol@reddit
i've yet to read the paper in depth, but from what I read they said a MAXIMUM of 9x for red code
it's true that skill is a major factor in codebase health, but I'd assume the research/article is making the argument towards adoption of tools that enforce code quality standards, where is often impossible to convince non-technical management that you need a budget for some devtool on the basis that "it'll improve some intangible code quality"
keeping a green codebase without assistance is definitely a fantasy for your run-of-the-mill dev team, but I wonder what would happen if you took a 50% percentile dev team and gave them unlimited access to Google's infra and tooling?
hippydipster@reddit
Guess I read it wrong then. At 2x speed only the math works out different and should probably rewrite red code almost never, as doing so isn't worth too much.
Yes, they want metrics to show code is green or red. Presumably they have those metrics, else where did they get their numbers? There's also the problem of lack of controls in studies like these, and basically always, its impossible to have any confidence these numbers represent anything real or objective.
Which generally leaves us with our intuitions, and we all disagree about those, so no one's willing to invest.
We need real experiments and studies with controls and pre-chosen hypotheses to get to a point where we can even begin to claim objectivity. I've always wanted to do such experiments, but they would be costly and difficult.
nephrenka@reddit (OP)
That's not what the article says. It states that "On average, developers complete tasks in Green code more than twice as fast as in Red code."
The 9x comes from the task variation measure: "Modifying Red code is a gamble, as tasks can take up to nine times longer compared to Green code, which has far less variation in task completion times." So, one take on this is that Red code makes guesstimating how long a task will take even harder. That adds to the stress and frustration of everyone involved.
Yes, there is a skill gap in our industry. My thoughts are that an objective measure of what good vs bad looks like would help. Without a shared ground truth, we'll have a hard time agreeing on _what_ skills to train for.
GimmickNG@reddit
This. Or put in simpler terms, if my grandma had wheels she'd be a bike :)
alexs@reddit
I think this thinking is backward. The optimal situation is for the practices of the engineering team to be aligned with the needs of the business.
There is no single definition of "good" that can even support a generalisable definition of something like green/yellow/red code.
If your job is to smash our marketing websites that are only going to exist for 3-6 months you simply have no reason to care about maintainability. If you spend more time by making it "green" all you've done is waste the clients money.
If your job is building software for a global monopoly search and advertising business, you probably care very little about new features and are more interested in things like operations and infrastructure costs.
If your job is a brand new SaaS startup you are probably starting more towards the first end of the spectrum and rapidly moving towards the second.
wknight8111@reddit
I've been on two projects recently where we had this kind of problem: bad code quality and a number of other ills (low or no test coverage, no scripting or automation, no "process" or tooling around code quality, etc). In these cases the unhealthy codebases were leading to serious project problems: large estimates for tickets, tickets that were taking longer than estimates (even when the estimates were very large), blown deadlines, blown budgets, etc. I had one project where it seemed like every sprint the release date moved further away and the team was completely floundering.
My general process for improving these projects goes something like this:
In both these cases the projects have gone from slow and unhealthy, to fast and confident. In one project I actually got a (lighthearted) complaint that the devs were closing tickets faster than the product team could add new tickets to the backlog! It's a good problem to have :)
I find a lot of coders really tend to treat the project as sacred in a lot of ways and are afraid of making big changes to structure, process, organization or standards. I also find that a lot of people initially don't understand the benefits of testing/refactoring/automation/analysis/etc but may be open to you proving it by example. Show them what the benefits are and they will support it even if they don't always understand it.
linlin110@reddit
The last paragraph reminds me of The Fear Cycle
wknight8111@reddit
I hadn't heard of the Fear Cycle, thanks for sharing.
What I'm talking about is a little bit more fundamental. It's not a response to making mistakes, it's a consequence of how developers are trained and gain experience: A junior developer doesn't do design work or refactoring because Architects, Leads and other Senior Devs have already done that work. Mid-level devs don't do that either. And when they become Senior-level developers they don't have any experience with design or refactoring, so they're too timid to start doing it. You rely on "somebody smarter than me" to do some of the complicated work until you get promoted and suddenly you're the smartest (or at least most experienced) person in the room.
A decision which has already been made and seems "good enough", even if it's causing problems, is hard to justify changing.
wampey@reddit
This all sounds amazing. Trying to get my team into the idea of it but they have yet to understand what all this does.
nephrenka@reddit (OP)
\^this. To non-coding decision makers (like PO/PM), code improvements don't have any intrinsic value: the system does the same thing after the code clean-up as it did before. That's why being able to put numbers on code quality improvements is important. As shown in the article, these can come with a demonstrable ROI.
djnattyp@reddit
The Fable of the Chicken and the Pig and Goodhardt's Law re: "putting numbers on code quality".
Do you ask your boss about the ROI of wiping or washing your hands on bathroom breaks, too?
kuraianlol@reddit
i might ask my boss about the ROI of installing a bidet in our office vs. time spent wiping...
how many engineering hours would it save annually?
rlbond86@reddit
This lets the PMs of the world off with an excuse.
They might not be software engineers, but it's their fucking job to understand the impacts of poor code quality. It's not like this is some kind of mystical secret. But too many PMs get away with being fucking morons.
wknight8111@reddit
A lot of coders will pout and say "I told them the code was bad but nobody did anything about it". Don't wait for somebody else to act! Become the change you want to see.
Decide for yourself that "Every single PR I open is going to contain a commit with cleanups/refactors/test coverage/other improvements". Within months or even weeks there should be noticeable improvements in measurable metrics.
spaceneenja@reddit
This is essentially my approach as well.
Code quality should improve “velocity”, higher velocity gives the business more bang for their buck.
Velocity is in quotes because if team members are honest, story points should drop over time. Real velocity improves, but sprint velocity should remain about the same.
sheckey@reddit
Great post, thanks. We’ve been doing similar things.
coopaliscious@reddit
I think we all want green code, but I'd argue most businesses need yellow code. Over optimization whether in processes or code itself has diminishing returns. "Good enough" can really be good enough in most cases. Businesses will strike a balance based on their needs, budgets and risk tolerance.
nephrenka@reddit (OP)
I'd like to argue that not all code is equally important from a maintenance/cost perspective. Parts of a codebase with low to no development activity can stay yellow. In other parts -- the development hotspots -- even a minor amount of technical debt will become expensive. (Check out https://codescene.com/blog/prioritize-technical-debt-by-impact/ for more details).
MisterFor@reddit
Exactly this. With my current team I have done 2 months of real productive work this year. And it’s going to be 10 months of moving things around, refactor and documenting rules. We don’t create almost any real value.
Yeah, that 2 months is yellow code. So what? It’s very easy to maintain and extend even if doesn’t look like something coming from NASA. And the teams and users that consume those applications are amazed by the results.
But the rest of the projects with the perfect green code? They move slow af because we have a thousand rules, and it’s not even dealing with money, health or anything like that. Trivial stuff built like NASA never gets deployed.
Too many engineering people don’t want to accept it but perfect is the enemy of done. And we are paid to do things, not to enjoy how clever we are.
In my case, those 2 productive months have people amazed, imagine what could have been with 8-9 months instead of 2! Instead we have to go to meeting and try to justify a whole year of refactorings and starting every project from scratch to be clean yada yada…
LessonStudio@reddit
I will suggest there are three arguments:
Liability. I've worked at companies making systems which are very much mission/safety critical; yet the code was trash. I could make about 50 bullet points detailing this trash; my favourite being no unit/integration tests for a 1m + loc system. One employee quit saying, "I don't want blood on my hands."
The lack of being able to prove liability. Generally, when there is a big disaster, there is never just one flaw. It is often a long chain of mistakes, an if any one of those didn't happen, then there would have been no disaster. The people overseeing the investigation will pick which link is to blame, and largely ignore the rest. Thus, there might not be as much liability as may seem obvious.
Technical debt. This is the more clear and present danger if you set aside the ethical questions from above. Code quality is technical debt; which is like a high interest loan. The more debt you accumulate, the more interest you have to pay. At some point the interest payments are in the form of nearly 100% of developer time. That is, they are fighting the debt far more than they are producing value. This is how many projects are stuck at 90%. Not only are they making interest payments, but the 90% is also bad accounting, as the existing code is shaky crap which really should be rebuilt.
This last is where it directly impacts business. Quite simply, if nearly 100% of your development budget is being spent on interest payments and not new features, then it is money wasted; and opportunities lost.
I've seen many tech companies become market leaders and then stop almost all new substantive features. People will accuse them of "riding on their laurels", but in most cases they are in a full on panic as they spend huge resources to produce almost no new features; as they watch in abject horror as their upstart competitors rush by them.
MrEllis@reddit
Liability is one of my favorite justifications honestly. Health and safety is the obvious case, but really you can get a critical answer just by how taxing on-call is for the team/company.
If you're correctly defining code quality (ideally not an unbounded pursuit of obsessive perfection) then code quality has a massive impact on the rate of bug escapes and on call events. You can 100% classify this as tech debt instead since every on-call event is an interest payment on a sub-par codebase.
However in a healthy on-call program on-call events only trigger when business liability is invoked, so every on-call event should be representative of an event that could have spiraled out of control and broken customer trust or otherwise compromised the product.
ChannelSorry5061@reddit
bad code, more time, more money spent
good code, less time, less money spent
CodeSherlockAI@reddit
Code Quality is of paramount importance of course. No code is perfect ever, however there needs to be conscious effort to keep the quality superior and production worthy. In my opinion a lot of developers also lack the knowledge of how to keep code quality superior. Especially the Junior ones. You need a coding guideline framework which helps you through the process. Code reviews while they help, tend to be very contexual, manual and subjective in nature. So when you write code, is when you try to keep the quality high by following certain simple guiding principles which help you build good code. For example, following a simple principle like Single Responsible Principle can take you a long way. Breaking down the system into entities and componenets helps build a more modular system. Then following a more Microservices architecture can help build a more scalable system. So quality guidelines and quality dimensions are very critical. One modern tool I can suggest which helps while you code with following quality guidelines is CodeSherlock.AI . It's available both in Visual Studio Code and Web. Check it out, it's based on guiding principles of better software architecture and you can improve code as you write.