This is a very important thing to learn. We shouldn't throw away old wisodm because it's hard to understand. That's exactly the learning that is most valuable to keep!
One thing I still wonder after reading this article though, is how can we tell the difference between code I don't understand and code that should be improved?
That's a good question, I was advised to cover it but I decided to focus on a single topic :)
It's hard to pinpoint the exact difference, but I would say that if you spend a couple of hours on a completely new code to you and still has no clue what's going on, it's a red flag. And after a day with a new repo you should be able to understand the main flows and what they do.
Very funny story, Anton with a great lesson attached. Be careful to not break what isn't broken! Refactoring certainly isn't free. As much as better code would be great, sometimes the "right" thing is far more effort and risk than just letting it do its thing
Great story! I do agree that there is definitely developer bias to just rewrite things instead of reading and understanding complex code bases. I have definitely been guilty of this. I dont really agree with the "old code is best code" assertion. It is true that old code is battle tested and hardened against all types of edge cases but I don't think this is a reason to not refactor often. I think you missed a subtle point in your very funny analogy of cleaning your father in laws back yard. To make the analogy more like coding we have to imagine that there is a robot yelling at you when you do something wrong (like getting rid of the compost). This, in coding is unit testing, integration testing, static types, etc. Imagine if you had a robot telling you what "not" to do when you were cleaning the back yard. How happy would your father in law have been if he had come to see the back yard cleaned of all the crap with all the vital pieces in place? Now, I do admit to achieve this you need good robots in place (good tests, etc).
But I have to disagree - great robots/testing helps you make the refactor seamless, but it doesn't mean you need to refactor often. To continue the analogy - the great robot was trained to shout at me if I try to throw away the compost. But after I refactored, my father in law decided he doesn't want it anymore, and put some other garbage-looking thing. So they next time I clean it up, the robot won't detect it.
When you do a thorough refactor, quite often you end up rewriting/changing a lot of the UTs to fit the new code, thus missing many bugs.
I'm not saying we should never refactor, but good test coverage is not enough to take that decision.
Your mother-in-law got your back 😂 Great story Anton and lots of learning!
At first sight, there's always something inviting and magical in the idea of starting from scratch. But we have to remind ourselves that most of the stuff we code isn't there to satisfy our curiosity and make work more interesting but to keep that money coming in. 🙂
This is a very important thing to learn. We shouldn't throw away old wisodm because it's hard to understand. That's exactly the learning that is most valuable to keep!
One thing I still wonder after reading this article though, is how can we tell the difference between code I don't understand and code that should be improved?
Thanks for the thought provoking blog today!
That's a good question, I was advised to cover it but I decided to focus on a single topic :)
It's hard to pinpoint the exact difference, but I would say that if you spend a couple of hours on a completely new code to you and still has no clue what's going on, it's a red flag. And after a day with a new repo you should be able to understand the main flows and what they do.
Very funny story, Anton with a great lesson attached. Be careful to not break what isn't broken! Refactoring certainly isn't free. As much as better code would be great, sometimes the "right" thing is far more effort and risk than just letting it do its thing
Thank you Jordan! :)
People often just estimate the time to refactor, not taking into account the huge risk that comes with it!
Very nice write up and also insightful
Thank you Temitayo 🙏
I loved that article. I especially enjoyed the story in the beginning. It is a great analogy.
Thank you Yordan! ❤️
Great story! I do agree that there is definitely developer bias to just rewrite things instead of reading and understanding complex code bases. I have definitely been guilty of this. I dont really agree with the "old code is best code" assertion. It is true that old code is battle tested and hardened against all types of edge cases but I don't think this is a reason to not refactor often. I think you missed a subtle point in your very funny analogy of cleaning your father in laws back yard. To make the analogy more like coding we have to imagine that there is a robot yelling at you when you do something wrong (like getting rid of the compost). This, in coding is unit testing, integration testing, static types, etc. Imagine if you had a robot telling you what "not" to do when you were cleaning the back yard. How happy would your father in law have been if he had come to see the back yard cleaned of all the crap with all the vital pieces in place? Now, I do admit to achieve this you need good robots in place (good tests, etc).
Thanks! Nice addition to the analogy :)
But I have to disagree - great robots/testing helps you make the refactor seamless, but it doesn't mean you need to refactor often. To continue the analogy - the great robot was trained to shout at me if I try to throw away the compost. But after I refactored, my father in law decided he doesn't want it anymore, and put some other garbage-looking thing. So they next time I clean it up, the robot won't detect it.
When you do a thorough refactor, quite often you end up rewriting/changing a lot of the UTs to fit the new code, thus missing many bugs.
I'm not saying we should never refactor, but good test coverage is not enough to take that decision.
Nice read
Your mother-in-law got your back 😂 Great story Anton and lots of learning!
At first sight, there's always something inviting and magical in the idea of starting from scratch. But we have to remind ourselves that most of the stuff we code isn't there to satisfy our curiosity and make work more interesting but to keep that money coming in. 🙂
Thank you Akos!
Engineers often forget that the business needs to make money first :)