Geek Answers Handbook

How to cancel code degeneration?

Imagine the following scenario: you will be asked to develop a tool from scracth yourself. You came 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 you are asked about the beta release date, you underestimate the time it takes to complete what, apparently, is just a little extra work.

You understand that you are going to skip the deadline if you have not cracked it. Against your best decision, you continue anyway. Beta is released, everything looks fine, and no one suspects ugliness below. Your plans to fix it during the testing of the tool are suppressed, because you are busy enough, eliminating small problems and adding features offered by beta testers.

At this point, you understand that your code is turning into a chimera. You are afraid for the controllability and scalability of the code. You really want to reorganize it, but it will look like you are not adding anything new and thus are not doing anything. What are you doing?

+4
source share
5 answers

I suggest that your boss knows that the code was written for a prototype. Unfortunately, you did not expect the level of maturity that the program is currently experiencing, and because of this, you need to revise the application core and optimize / rebuild its base so that the program is more scalable. Make sure that the new feature requests you filled out were not part of the plan when the base system was developed. As a result, restructuring is necessary to ensure that these changes and future changes do not cause the application to become unusable due to random errors that users find that you cannot reproduce in your development environment. Emphasize what the current system will do (not to imply that you did not do your job properly), but the changes you propose to make will improve its scalability and reliability to add new features and fix future problems.

:)

+2
source

The next time you should not underestimate the time required for functions. Evaluation is a bit of a black art, and you have a 99.9% chance of making a mistake, the trick is to make a mistake in a positive way.

If you evaluate 2 weeks for a shift and go there or under it, then you, the boss, will love you for it, even if you had to almost kill yourself and work for 18 hours to achieve this. If you rated 4 weeks instead and did it in three, your boss will still love you the same way, even if you are 50% longer than in the first example.

When coding, several skills are required, and the ability to write in the specified language is only one of them, the other able to manage expectations. You will never get it accurate, but getting good on it will make your life easier and your work will be much nicer.

+4
source

If this program should be developed, that is, this is not the latest version, and probably new features will be added, I would suggest preparing yourself for conversations with your superiors about the current status of the project

Call their attention and share with them how the project has become and explains (using the best of your communication skills) that this characteristic is an integral part of the project's origin. Sometimes this happens, and code refactoring is designed for these situations.

+2
source

When working on large projects, always try to disseminate your results over time:

  • release functions 1,2 and 3 in phase 1,
  • retain functionality 4 and 5 for phase 2, etc.

Make sure that only the initial AF planning phase is completed, and while working on phase 2, make sure you have time to finish the free ends left over from phase 1.

And, as zcourts suggests, there is a fundamental difference between a prototype and a production system: prototypes are used to test the rationale or rules, production systems work with proven rules. Never skip the steps between validation and application.

does that make sense?

0
source

More articles:


All Articles