Imagine the following scenario: You are asked to develop a tool from scracth, by yourself. You come up with a prototype and they like it.
Against all odds your prototype survives and matures. There is a code review and everything still looks good. Your manager
pats you on the back. Unfortunately, when asked of a beta release date you underestimate the time required to complete what seems to be only a little bit of extra work.
You realize you are going to miss the deadline unless you hack the features into it. Against your best judgement you proceed anyways.
Beta is released, it looks OK and nobody suspects the ugliness underneath. Your plans to fix it while the tool is being tested are foiled because
you are busy enough fixing small problems and adding features suggested by said beta testers.
At this point you realize your code is turning into a chimera. You fear for the manageability and scalability of the code. You really want to refactor it, but that would make it look like you are not adding anything new and thus not doing any work. What do you do?
I suggest letting your boss know that the code was written for the prototype.
Unfortunately you hadn’t foreseen the rate of maturity the program is now experiencing and because of that, you need to revisit the core of the application and optimize/remodel its base to allow the program to be more scalable. Make it clear that the new feature requests that you have been filling had not been a part of the plan when the base system was designed. As a result the restructuring is necessary to ensure that these changes and future modifications do not cause the application to become unusable because of the random bugs that users will find that you may not be able to reproduce in your development environment. Emphasize the point that the current system “will do” (so as not to imply you weren’t doing your job properly), however the changes you’re suggesting be made will improve its scalability and reliability for adding new features and fixing future problems.
🙂