Clean Code Is Killing Your Projects

Everyone wishes they were able to write cleaner code, but sometimes going back and refactoring code so it is cleaner is actually a bad idea. In this video I talk about the hidden cost of refactoring and some tips on how to do it right.

🌎 Find Me Here:

⏱️ Timestamps:

00:00 - Introduction
00:47 - My Story
05:00 - Tip #1
06:31 - Tip #2
07:48 - Tip #3

#Refactoring #WDS #CleanCode

[barrykruyssen]

Spaghetti code is the death of a project. After 40+ years as a software engineer (retired now) this has been my experience. And as Kyle found out taking over a project it is very difficult and refactoring is even more difficult. Clean code, small individual functions and remember the code should be readable by humans first. Kyle does great videos.

[mcmanussean]

Great advice! (20-year software engineer here). I'm surprised you didn't use the term "tech-debt", that's basically what you're describing. I think of addressing tech debt the same as addressing financial debt. You don't pay off 100% of your credit cards and then not pay your rent and buy food that month... You pay off a chunk at a time when you can afford it. If you address tech debt the same way (basically what you were describing) eventually your tech debt will be at a more reasonable level.

[playmaker]

I was literally doing unnecessary refactoring this exact moment haha, what's so special about kyle is that he doesn't just teach you how to program, but the best, most optimal practices!

[some_guy_with_a_hat]

This is something I always have trouble balancing. We had some really bad developers in the past. I'm frequently refactoring their projects, removing 90% of unnecessary code, getting massive performance gains, and fixing a few corner case bugs. There's so much to fix though, and I need to work on other projects too.

[adamgoldsmith]

You nearly got me with this one haha, overall great advice, using an iterative approach means that you can do small refactorings, and target areas of the code you are going to change next, I find that writing tests to capture the behaviour of your code before starting a refactoring is pretty much essential too, if you code doesn't have tests before you do this, it will after, this is also a good way to get into TDD

[paulthomas]

Hi Kyle, I've been a software engineer for longer than I'd like to admit to 🤫 and I totally agree that the refactoring effort can be a pointless and expensive portion of some projects. I worked on a large banking project for a well known UK finance house and spent (along with my team) way too long on refactoring code only to add more issues and cost. I understand the technical reasons but sometimes 'less is more' - it's a cliche I know but doing nothing sometimes beats doing lots !! - love your videos and all the best from UK !

[zoonvanmichiel]

Fully agree. And even if you do a large-scale refactor; do it in small steps. With your anecdote: a lot less time would have been wasted if you regularly merged the code into main and got to experience the benefits with implementing the new features. It also makes sure it is more in sync, you don't want a branch of a version that is a month old.
The only large-scale refactor I had to do was a case where our data model did not match the data model of the source. So when they had a new feature, we could not implement it. But that refactor had a lot of planning to break it down in small steps.

[robertholtz]

Refactor as you go. Ideally, think about the problem you’re solving in an abstract enough way that future iterations don’t need to be refactored to be extended. If you’re about to put a band-aid over another band-aid, refactor that section.

[taylorkoepp]

I've been a professional programmer for over 20 years and this is great advice. When I started spaghetti code was the norm, not the exception. I don't suggest that was better but it's very easy to watch a tutorial on some perfectly implemented design pattern and then think there's something inherently wrong with your less than perfect implementation that's currently in production and working adequately. I wish I'd realised this years ago!

[Bgrosz]

Refactoring iteratively is excellent advice.

In your scenario, if you have new feature requests coming in and you don't know how much time you have available then you can't commit to a huge refactor.

I refactored constantly, but often it was just the code file I was working in and small and easy refactors to make the code easier to read and update. I did plenty of large refactors, but I always knew I had the time available to do those before I had to add new features.

Basically, if you're going to do a large refactor, then make sure the boss knows you need X weeks to just work on that.

Your 80/20 advice is also excellent. If you can easily read and understand what the code is doing and it reasonably efficient, then your time is better spent elsewhere.

[MrMaramor]

All in all, good info. I typically start with, plan, get it working, then look at flow and performance improvements, set a time limit for each part. Definitely set limits and add dev notes if you have ideas for the next iteration or next developer to consider. Smaller changes are usually more focused. If you have a team, peer review can also be helpful. There is also value in putting it down for a while and coming back to it.

[yehielamar]

That's the role of a software architect, planning before coding is key in my opinion

[scigama]

if you put 5 developers in a room to develop an app. I bet they will all do it differently

[Homiloko]

Clean and maintainable code always wins in the long run. You should always write well structured, understandable code.
The thing you don't need is extremely optimized code for performance, that can come later when you actually reach a bottleneck and improving performance becomes a goal. Oftentimes, the time you'd spend gaining a few extra cpu cycles wouldn't even be noticed by the consumer.
As for refactoring, you never have idle time to work on that. The way I do it, is I only refactor the classes and methods that I'm using directly in this new feature or patch that I'm working on. It's that idea of always leaving the place cleaner than when you entered. You do small (or large) refactorings along the way to achieve your goal, and the refactoring never becomes an activity in and of itself, and then you don't ever need to convince your managers and higher ups to alocate time for this (because they won't want to, they usually only care about the finished product).

[punkypinko]

I promise, most devs are not spending too much time refactoring. They are writing 90% spaghetti code.

[at]

Thank you for bringing this up! I saw a lot senior developers wasted a lot budget and the product couldn’t never get out !

[Rachoszsky]

You didn't refactor the code, you did a rewrite. That's an important difference!

[Michael-shfb]

"Refactor small bits at a time".

If you lookup what 'refactor' originally meant, it's always small, by definition.

People use it as a fancy way of saying 'rewrite' but that's not what it originally meant.

[justine_chang]

i'm so glad to watch this video, because this sounds super similar to something I've done in the past too. Now I'm very cautious when it comes to committing to refactoring, and very cautious about updating / upgrading anything in the stack. I think we should only update is there's a bug in an older version, or there's a new feature we need in a newer version.

[vitvitvitvitvitvitvitvit]

I am experiencing something like what you went through when you were a fullstack developer. I do all the coding at my company (frontend with React and React Native, backend, deployment, etc.). I always want to refactor all the code because the me of two months ago was dumb. The worst thing is writing refactored code, which is supposed to be better, and it's not. I hate programming alone, but I think it's good in a certain way. Thanks for the tips! :)