How to reverse degeneration of code?

Question

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?

Answer 1

Check out how-do-you-justify-refactoring-work-to-your-penny-pinching-boss

Answer 2

If this program is meant to evolve, meaning this wasn't the last version of it, and probably new features are going to be added, I would suggest preparing yourself to talk with your bosses about the current status of the project

Call their attention and share with them how the project came to be and explain (using the best of your communication skills) to them that this characteristic is intrinsic to the origin of the project. Sometimes this happens and code refactoring is meant for these situations.

Answer 3

Next time don't underestimate the time required for features. Estimation is a bit of a black art and you have a 99.9% chance of getting it wrong, the trick is to get it wrong in a positive way.

If you estimate 2 weeks for a change and come in on or under that then you boss will love you for it, even if you had to almost kill yourself and work 18 hour days to achieve it. If you had estimated 4 weeks instead and got it done in three your boss would still love you just as much, even though you took 50% longer than you did in the first example.

There are multiple skills required when coding, and being able to write in the specified language is just one of them, another is being able to manage expectations. You'll never get it exact, but getting good at it will make your life easier and your job a lot more enjoyable.

Answer 4

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.

:)