As I'm primarily working with databases, we're still dealing with a huge relational monolith that has been created like 10 years ago, perhaps more.
Lots of production objects are dead (not used, or wouldn't compile anymore)
Objects that were supposed to go to production but never did are there
Databases calling objects from other databases in a manydirectional(?) way
Mixed up naming conventions
Lots of dynamic SQL
Business layer and sometimes even presentation layer has been put to database, primarily stored procedures which means changes often have to be done in many places and tracked
Lots of quick fixes and hard-coded conditionals
So yep, most of these changes mean that sometimes we're making changes on old objects that will not make an impact at all. There's a huge risk of breaking things apart, risk that someone will forget to make a change in one place due to hard-coding.
I'd say that root cause is the way teams have been structured.
Physically, our department is just database department and we're supposed to deal with SQL. We're all co-located.
We've also got web development teams in other physical locations.
Now the issue is that SQL team doesn't know much about web codebase and technologies that product has been built with but knows business domain very well and underlying data structures (or at least is supposed to know).
Web team knows codebase but knows very little of SQL and domain logic.
And when you have to remove some dead code, it's quite a painful process because scrum teams are busy with sprint work and debt stories usually are somewhere at the bottom and are left behind due to higher priority work.
Of course, this does sound bad, but some of our managers (not every) are technical people and see value in technical debt removal. This moves on, but slowly.
Also, teams are now becoming more collaborative and try to enrich their skill set which will (not I shape people, T shape, E shape, all these buzzwords) which will help out to understand not just the one side of code, but the whole picture.
Oh man, are you sure we don't work at the same place? ;-)
I work with most of the above issues (10+ year old monolith), along with hard-coded values that get forgotten in some old dusty corner of the codebase and cause bugs without generating any actual errors!
In our case, management are all non-technical and don't really understand the difference or the business value in good code vs. bad code, or tech debt or any of it, really. And in many ways, that old code worked and got them to this point...but at some point you do start to pay the price.
I guess I'm not the only one crying about issues we have!
Technical debt is just like a loan. You have to pay every month for it, at the end of your month you didn't really earn anything but you're in a much better shape.
During these few years I've realized that it's difficult to sell this kind of work for management, but it's possible, you just have to learn to speak their language:
Shorter development cycles
Less bugs
Faster deployment times
Possible infrastructure savings
Ability to ship new features faster
etc.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My current codebase!
As I'm primarily working with databases, we're still dealing with a huge relational monolith that has been created like 10 years ago, perhaps more.
So yep, most of these changes mean that sometimes we're making changes on old objects that will not make an impact at all. There's a huge risk of breaking things apart, risk that someone will forget to make a change in one place due to hard-coding.
What's primarily preventing folks from removing dead code at the moment?
tl;dr; People don't know to.
Proper version:
I'd say that root cause is the way teams have been structured.
Physically, our department is just database department and we're supposed to deal with SQL. We're all co-located.
We've also got web development teams in other physical locations.
Now the issue is that SQL team doesn't know much about web codebase and technologies that product has been built with but knows business domain very well and underlying data structures (or at least is supposed to know).
Web team knows codebase but knows very little of SQL and domain logic.
And when you have to remove some dead code, it's quite a painful process because scrum teams are busy with sprint work and debt stories usually are somewhere at the bottom and are left behind due to higher priority work.
Of course, this does sound bad, but some of our managers (not every) are technical people and see value in technical debt removal. This moves on, but slowly.
Also, teams are now becoming more collaborative and try to enrich their skill set which will (not I shape people, T shape, E shape, all these buzzwords) which will help out to understand not just the one side of code, but the whole picture.
Oh man, are you sure we don't work at the same place? ;-)
I work with most of the above issues (10+ year old monolith), along with hard-coded values that get forgotten in some old dusty corner of the codebase and cause bugs without generating any actual errors!
In our case, management are all non-technical and don't really understand the difference or the business value in good code vs. bad code, or tech debt or any of it, really. And in many ways, that old code worked and got them to this point...but at some point you do start to pay the price.
The monolith lives on.
I guess I'm not the only one crying about issues we have!
During these few years I've realized that it's difficult to sell this kind of work for management, but it's possible, you just have to learn to speak their language: