#CodeQuality #MaintainableCode #GoodCode
Hey there! I totally get where you’re coming from. It can feel like a never-ending battle to maintain good code, especially in a large corporation with tight deadlines. But fear not, not all codebases are destined to turn into bad code! It’s all about the approach and mindset you have towards your codebase.
First off, let’s debunk the myth that good code is impossible to maintain in a large corporation. While it may be challenging, it’s definitely achievable. With the right strategies and mindset, you can ensure that your codebase remains maintainable and of high quality.
One approach is to prioritize code reviews and refactoring. Encourage a culture of code reviews within your team, where everyone can provide input and catch potential issues early on. This helps in maintaining the quality of the codebase and ensures that bad code doesn’t sneak its way in.
Another helpful practice is to invest in automation and tools that can assist in maintaining code quality. For example, utilizing code analysis tools and continuous integration can help in identifying and addressing any code quality issues before they escalate.
And remember, good code is not about perfection, but rather about constantly striving for improvement. It’s okay to have “good enough” code that meets the requirements and is maintainable, rather than aiming for perfect code that may never be achieved.
So, to answer your question – no, not all codebases are destined to turn into bad code. With the right approach, mindset, and practices in place, you can maintain a codebase that stands the test of time.
Keep coding and striving for maintainable code! You got this! 💻🚀
It’s definitely possible if people don’t use the excuse of ‘deadlines’ to produce shitty work 🙂
People tend to add code without considering the long-term ramifications of doing so. It is absolutely possible, but it is hard to keep a codebase healthy and requires a lot of discipline throughout the entire lifecycle.
The truth is that most developers aren’t very disciplined, and as a result we end up with codebases which reflect that.
One of our leads wants to be using modern development practices so that’s good.
I go to Azure DevOps to configure deployment for this app, the API that’s for this project only is setup separately, copied, pasted and published separately from the single solution which houses the main project alongside the API and it’s named a generic “API” so if we house it in our test server as a project of its own you can’t tell what it’s for. Well, at least he nested it in the main project (which already has the published .dll of the API in there, why configure it twice?).
Then he asks me “Don’t you have more important things to do?”. Well, you took off today so I thought I’d have time to setup deployments. Instead this is another “take time off to code so I don’t have to answer support tickets” day.
It’s not easy out here.
Yes. Unless you work at FAANG or a tightly nit company, your only goal is to get experience, learn, get paid, use learnt experience to hop to better companies.
In business good code makes money. Bad code is anything that might hamper that. In business money today almost always wins over possible money tomorrow
We had a large code base here – that the staff had to support 24/7 – since they knew if something broke, I would get a call and they would get a call to fix it – even if the middle of the night – we kept that codease as a ‘good codebase’.
But it took time, Discipline and resources to ensure that it stayed a good clean codebase. Having long term staff – made that job a LOT easier.
This!
I have been working at my current company for the past 3 years and have seen the codebase evolve through a series of pull requests and undocumented commits.
A lot of the code you write will be maintained by someone else and that’s a fact you can’t change. I suppose this is the sole reason why most software engineers hate delegating tasks to others.
To add to that there are deadlines which do nothing but make folks implement hot fixes and a bunch of quick dirty code. -_-
Nah, not all codebases are doomed to go bad. It’s a common struggle, especially with tight deadlines and team changes, but good code is definitely achievable. It takes a combo of solid coding standards, regular refactoring, and a culture that values code quality as much as meeting deadlines. Sure, it’s a balancing act, but with the right practices and management buy-in, good code can be more than just a dream
Dude, any code that exists is already legacy, that’s just how it is.
Bad code is subjective. What matters are the end product, performance and documentation.
Yes. Pursuing “good code” is often a waste of time and a pipe dream. You can argue the long term benefits of consistently writing “good code”, but it’s difficult to quantify. It’s also a trade off in terms of code velocity.
It is more reasonable to pursue code that is “good enough”. Is it a work of art? No. Well, does it work and not introduce practical code debt? Ok, fine.
Yes
2nd law of thermodynamics. Yes.
All code is bad.
if technology is ur product, it actually matters, or will matter after you push the 20th bug to production.
no excuses for anything but 90+% test coverage. you have to know something works. formatting guidelines, have some standards, both in your life and work in general.
if the codebase is shit its up to you to unshit it. if you want a serious product anyway. backend tests. frontend tests. actual proper ci/cd & easily reversible deployments.
a messy codevase is the professional equivalent of a messy room
Can’t just ship it and forget it.
There’s no set fate and they theoretically could be maintained if good code was a measurable performance objective (and thanks to linting and other formatting tools being built into CI/CD pipelines, it usually is). However, the overarching goal at most companies is to push features and bug fixes, and employees are promoted based on those KPIs, so over the long term, codebases generally tend towards being a mess, especially with employee turnover.
small company with avg. tenure of 10 yrs = good code
large company with avg. tenure of 2 yrs = bad code
experienced both.
Stop following good code and focus on good business.
Code is mere a tool to improve the business.
There is no universal definition of a bad code base.
I will say that every code base is destined to turn into something that someone considers bad.
bad code in which repo? the small one your team sets and forgets?
Or the huge one everyone shares and nobody owns?
It’s basic physics Order tends to disorder
No, but it’s a lot of sometimes painstaking work to keep it healthy. And it requires lots of experienced and caring people, too.
Yes. When successful they bring more people on to mess it up.
When unsuccessful, they keep the one guy to keep it’s lights on.
The best code I’ve seen is code for smaller, single responsibility systems. Then any other system that wants to use it calls it via an API, so I mean basically microservices. It’s much easier to maintain many smaller projects behind well defined APIs as it forces you to think about what you’re actually exposing which tends to lead to better design. I think you can have good code but I certainly won’t say you could ever have code that adheres to every principle of what it means to be good code, partially because that’s often subjective but also because it’s sometimes just not feasible with many people working on the same project with varying skill levels, priorities, and time.
Only if you have egotistical engineers and/or a company culture of delivery being the means to promotion or higher compensation.
No. I worked at a company that has two products that are over 20 years old. Both have the same tech stack. Both have been led by the same engineers since they were started.
One has code that is a beautiful work of art. The leader of this team has always been disciplined about code reviews and following coding standards. PRs get rejected all the time until they are good enough. It’s very stable and easy to make changes.
The other code base is a steaming pile of garbage. They didn’t do code reviews until the product was like 12 years old and it was mostly just for show. PRs rarely get rejected. No coding standards. Engineers do whatever they want however they want. It’s full of bugs and it’s so difficult to make changes.
So with discipline and standards your code can be beautiful forever but it takes work and a culture of excellence.
You need to “circle the wagons” when it comes to tech debt. Tech debt is inevitable, but it doesn’t have to be permanent or enduring. Ideally, you want your product teams to prioritize cleaning up tech debt. Realistically, you have to find ways to negotiate or “sneak in” small improvements.
Tech debt builds “interest” and you’ll have to pay on it. What you’ll find is that there’s not an exact monetary value placed on this tech debt and like many things it’ll fall by the wayside because of the inability to quantify it.
This is where you need soft skills to advocate for those improvements. This is something I’m working on.
This is such an overtly pessimistic thread, and the thought terminating cliche of “all code is bad” keeps getting trotted out.
The answer is of course not. I’ve worked on a very large legacy codebase at a FAANG that wasn’t _great_ by any stretch the imagination but it was clear that the people writing the code gave a shit.
What kept it decent?
– A ruthless documentation culture
– a collection of extremely specific ErrorProne lints
– an integration test suite that would immediately go red if you even coughed on the code
– fuzzing, mutation testing, property based testing – we did all of it.
– a cohort of extremely well compensated staff engineer
You have 20 people touching your codebase and leaving the team. No matter how it is designed to be a wonder it would eventually become a shitole
It’s entropy. Good code requires constantly fighting back against all the forces that lead to bad code:
* High staff turnover
* A cultural separation between thinkers and doers
* Deadline pressures
* Inexperienced developers
* De-motivated or apathetic developers
* Inexperience with the technology being used
* Requirements churn without enough time to refactor
* Incentives leading towards complexity
* Promotion process preferring complexity over simplicity and elegance
* Cultural emphasis on edge cases
* “Job security” through obscurity
Pretty much, I’ve never seen a large code base that isn’t dog shit. Hell, even if I look back on my own code from a year ago I’d consider it shit.
Sad reality is the people in charge of the coin don’t care enough to pay for keeping code clean. Even if they did, devs barely ever agree on what clean actually means for a given area anyway, so it ends up just being whichever dev complaining into the void of product people who have no idea what they’re talking about anyway.
Please define ‘good code’ in an objective scientific sense.
I dont think its possible to even define good code much less have it in a code base.
Preventing bad codebases requires that organizations do two things which many are unwilling to do:
1. Allow enough time to implement a feature the cleanest and most maintainable way.
2. Allocate time to paying down tech debt.
I love my job, but we admittedly struggle with both of these things, despite my efforts to advocate for them.