How Deleting My Code and Starting from Scratch Helped Me Write Better CodeJake LambBlockedUnblockFollowFollowingMay 24For the past few weeks I’ve been working on a project where I’ve found myself deep in the weeds far too many times.
Whether it was implementing some piece of functionality, getting a test to pass, or properly using design patterns; I frequently found myself spending far too much time on singular problems.
I believe the biggest contributing factor to this was my unwillingness to delete what I had and start fresh.
I fell victim to the Sunk Cost Fallacy.
I was under the impression that I would be able to fix and adapt my messy, poorly structured code in less time than it would take me for me to start from scratch.
Because I had already invested so much time and effort into getting to where I was, starting over seemed like a complete waste of time.
In reality, I was actually wasting time trying to fix the mess of code that I had created.
See, what I failed to realize is that the knowledge I had gained from working on the original version was well worth the time I had spent on it.
I didn’t need to try and fix what I had in order to get a return on my investment.
I needed to realize that is was time to move on from this version and use what I had learned to build something better.
But what lead to my code becoming so poorly designed that it required a full re-write? When I first started on this project I didn’t fully understand the scope of the project or what steps I should take to make a well-designed piece of software.
I just looked at the acceptance criteria for the project and started writing code to try and meet those requirements.
I didn’t really take into account how these pieces would interact or how the app should ultimately come together.
I was eventually able to meet the acceptance criteria but the product I had in the end was poorly designed and hard to make changes to.
When I came to this realization, I thought what my project needed was a major refactoring.
I started making changes to implement a new design that an advisor of mine and I had come up with.
After a while I was running into many errors as well as having to constantly fight with my code and tests in order to make progress.
The problem with what I was doing was that the design pattern I wanted to implement was so fundamentally different than what I had, that I would have to touch nearly every file in the project in order to implement it.
However, I realized this far too late into the refactor and was needing to wrap up and move on to my next project.
This isn’t the first project I’ve ran into this issue with either.
About a month ago I was working on something called the bowling game kata.
The point of the kata is to help you practice good design and test driven development.
After a few days of writing code, getting tests to pass, and trying to figure out how you actually score bowling; I finally got all my tests passing.
Looking back now, the code I had was a mess and far less than ideal, but I was proud of it at the time.
The first iterationI showed one of my co-workers what I had and he had more than a few comments.
I made some changes based on his feedback and then brought it back to him.
We had this back and forth one or two more times before he suggested something that, at the time, I thought was pretty radical.
“Jake, try deleting what you have and starting over.
” I was confused, I had just spent days getting this thing to work and he wanted me to delete it? I was very hesitant, but he was persistent.
I finally gave in, I didn’t delete my code but I did make a new folder and started from scratch.
Thirty minutes later, I had made something an order of magnitude better than what I had just spent two days making and trying to refine.
I brought my newly made kata back to my co-worker and he seemed very pleased with the progress I had made.
The second iterationBefore I had that interaction, I had never thought that deleting something I had spent so much time on, in order to do it better, would actually save me time.
I was so wrong.
Had I continued to try and fix my original kata, I would have probably spent days trying to reach the level of quality I achieved by starting over.
When I finally took the advice of my co-worker I was able to learn a few pretty important lessons:1.
) Starting from scratch gave me the opportunity to learn from the mistakes I made and issues I came across in the first iteration and then refine my process and approach the second time around.
2.
) When starting from scratch, the code that I write is not being influenced by my current implementation or flawed design.
3.
) I was able to come up with a much better solution to the problem the second time around in a fraction of the time.
Clearly, I’m still learning this lesson.
Looking back on my latest project, I’ve found myself in the same situation as my bowling game kata.
But this time I took too long to realize what I needed to do and now I have to move on to my next project.
But that’s ok, this project was a learning experience and will serve as a reminder of the steps that I can take to improve my work in the future.
Publishing Note:This article was originally published on December 10th 2018.. More details