Most people fall for the songs of the unwritten-code. When confronted with existing code, they can see all of the unevenness of the terrain, the special cases that needed to be shoe-horned because the original architecture didn't allow for them. It is at this time when the unwritten-code starts luring them inside their heads, a sweet, seductive melody. They (who am I kidding, we) think of a perfect generic architecture which will take into account all cases. This architecture will be so extensible that when new requirements arrive, it will take care of them without mutating the design. And performance will be equal or better.
It's all good, if it wasn't for one little problem. Unwritten-code is non-functional. Until we sit down and spend weeks --yes, weeks-- working on it, it's absolutely useless. What is worse, once we start getting better clarity on the domain, we start to understand what those architectural bumps were on the original codebase. At best, our new architecture will be better than what existed before, but our codebase is yet to be tested on the wild.
Oh, the wild, the proverbial real world where code is tortured in ways that we failed to imagine. If your code runs on a server, you may be lucky. Given the continuous feedback, you can patch it and evolve it, effectively reacting to the environment where your program runs. But if you pack it in a released form and part with it, then you're in for a ride.
There's a few rules to heed when rewriting something that's readily available, they are:
1- You are an expert in the domain of what you're rewriting. You're only an expert iff you've written the previous codebase and maintained it for years or you're an user of the codebase and worked with it for years. Yes, years.
2- You have the time and disposition to claim ownership (design, implementation, unit testing, functional testing, maintenance) of this code. It's like having a baby, you have to see it through College.
So, what to do? Write new functionality using existing parts. The value is on the new parts, and since they're new, there are few or no experts, and anyone can go ahead and explore that vast unknown.
It's all good, if it wasn't for one little problem. Unwritten-code is non-functional. Until we sit down and spend weeks --yes, weeks-- working on it, it's absolutely useless. What is worse, once we start getting better clarity on the domain, we start to understand what those architectural bumps were on the original codebase. At best, our new architecture will be better than what existed before, but our codebase is yet to be tested on the wild.
Oh, the wild, the proverbial real world where code is tortured in ways that we failed to imagine. If your code runs on a server, you may be lucky. Given the continuous feedback, you can patch it and evolve it, effectively reacting to the environment where your program runs. But if you pack it in a released form and part with it, then you're in for a ride.
There's a few rules to heed when rewriting something that's readily available, they are:
1- You are an expert in the domain of what you're rewriting. You're only an expert iff you've written the previous codebase and maintained it for years or you're an user of the codebase and worked with it for years. Yes, years.
2- You have the time and disposition to claim ownership (design, implementation, unit testing, functional testing, maintenance) of this code. It's like having a baby, you have to see it through College.
So, what to do? Write new functionality using existing parts. The value is on the new parts, and since they're new, there are few or no experts, and anyone can go ahead and explore that vast unknown.