DEV Community

Technical debt so bad I quit my job

Chris Oliver on February 04, 2020

When I got my first full-time development job, I thought things were going to be great. I thought I'd learn all kinds of things, see how a real dev...
Collapse
 
waylonwalker profile image
Waylon Walker

Thanks for sharing such an impactful story! I agree that a good refactoring is so rewarding! I like to try to set my projects up for easy refactoring as much as I can. In the beginning everything may be in one file, but settings are stored in a data structure that lends itself to being pulled into a settings file or a database, not haedcoded in. Functions are small manageable pieces with sane default inputs. Code smells such as data clumps are avoided as much as possible, or are setup for annexit strategy if certain things grow legs.

It's important to not necessarily start out with the final draft, because it's common to make the wrong call. Things become too abstract and hard to follow. Too many separate functions with things put in odd places make them hard to find. It's much easier to see the logical architecture after getting started for awhile.

Collapse
 
excid3 profile image
Chris Oliver

💯

Collapse
 
tj_skates profile image
Trent Nicholson

Crazy this is almost exactly how my current internship is going

Collapse
 
jorenrui profile image
Joeylene

Same.

Collapse
 
aminmansuri profile image
hidden_dude • Edited

I hear what you say and sympathize.

At the same time many mature projects come with technical debt. One project I started working with had almost a million lines of code and no comments when I joined almost 15 years ago. At that point the project was maybe 5 years old and already had technical debt. But the project is still alive today and the codebase is 20 years old.

However, experience in the field has taught me that most mature projects have this and that you just have to deal with what you get.

I made a bit of a name of myself in this project when (during the first months) I was able to refactor a major component of the software and make it much cleaner and more understandable. It was no easy feat but made the code much better. I later went on to rewrite another feature (improving it at the same time) and allowing them to remove several thousand lines of code. The lead programmers even accepted my radical changes because they were compelling enough.

However, I've also learned that a lot of refactoring means that you spend less time making new features that will make you competitive in the marketplace so we need to take care where we're spending our resources. Many companies went broke doing this. Some famous cases come to mind like WordPerfect and Netscape which engaged in full rewrites.

Architectural Erosion is often a fact of life in large projects with many developers coming and going. So as new programmers we need to learn how to fit in and contribute. That is not always easy, especially if everyone is terrified to touch anything, but its a fact of life in mature products.

Collapse
 
rachbreeze profile image
Rachel Breeze

Been thinking about this, if code needs weeks of handover and the lead dev still feel they can't relquinsh control of the code base is this a reflection on the developer's drive to lead, lack of trust of the rest of their colleagues (who are all proven developers), or a sign the code base has far too much tech debt in it?

Collapse
 
daytodatainc profile image
daytodatainc • Edited

Man, what a great read! Love the expression technical debt! It makes sense. I like to start off with concepts that make sense and branch off into some dependency. For me, it helps me understand how scalable my code really is. Not to say, I don't go back and refactor :-)

Collapse
 
ilvalerione profile image
Valerio • Edited

That was my experience too. I started ny career as software engineer at Ericsson.

It was super exciting at the beginning. Maybe in 4/5 months the sad reality comes true.

Old tool, old people, old software, bad processes...

I left Ericsson two years later starting my own company that build developer tools to solve the problems I experienced in my previous experiences.

In some way it was tough but useful for my life.

Collapse
 
jakl profile image
James Koval

I remember working there with you and totally agree that custom Perl ORM/Web framework monolith we used had a lot of issues. At least it was good impactful work. Hope you're well!

Collapse
 
excid3 profile image
Chris Oliver

James! Long time no chat! I'm doing fantastic. We should definitely catch up sometime.

It sure had a lot of issues, but it was incredibly important at the same time. Just makes me imagine what could be done with good code and impactful work.

Collapse
 
jakl profile image
James Koval

Ya for sure I'll let you know if I'm in your area. I'm traveling more with a solar camper van I built.

Collapse
 
alexantra profile image
Alex Antra

One of my previous lives I worked for a national loyalty company steeped in a decade of tech debt. Someone quit every fortnight, to the point where people purchased stamps or stickers for all the leaving cards.

For a solid year they worked to phase off of old tech and promised to never return to the days of so much tech debt.

However they had cheaped out on the new stuff and most of the platform never passed the MVP stage before it started to crumble.

New management changed all of our contracts to reflect that we would support MVP systems.

They still have super high attrition and most of their projects are in development hell.

Collapse
 
msfjarvis profile image
Harsh Shandilya

This is literally the reason why I quit my job. Only one person other cares about it and he ended up redoing our flagship product without all the garbage and debt so that we'd have an actual product.

Collapse
 
rails4business profile image
rails4business

THANKS!

Collapse
 
kerbrose profile image
Khaled Said

a lot of people get it the hard way. happened to me too