I am working with ASP.NET Application. The application is great and works fine but it a few flaws. To give you an example,

  1. Every control uses an absolute position layout. This makes working with code very difficult in design mode. Absolute position has been used more than 700 times in the code.

  2. There are different menus uses instead of one. And to stitch them together, again absolute position is used for each menu control

  3. The application is role based. All the roles are implemented using Roles.IsUserInRole property. I would like to use proper permission for every role with page level permission.

  4. There are a few security risk in the current code but that is easy fix in current program though.

  5. There is no true admin. The top level role act as admin which is also a functional role, used by other members.

Now that we are adding new functionality to this code and I mean adding some big functionality, what do you recommend. Should I rewrite this code or work in the existing. I would esp like to fix

  1. The layout issues. Remove all fixed positions and make the code clean and easy to maintain.
  2. Unfortunately to do so I have to rewrite the menu. Because I want to write one menu instead of 4 being used.

  3. In order to achieve point 2 above, I have to crete new roles and provide proper security for the application.

My question is

Should I work with the current code or rewrite the existing code keeping in mind that our company is growing and that it may take me 2-4 weeks to do rewrite up.

Would it be bad idea or a good one. I don't have a technical lead in my company.

2 Answers 2


From the description you gave, I would do a "divide and conquer".

Choose a smaller part of your application with which you have issues, and improve that, either directly, or (safer) indirectly by coding a new version, leaving the old version as is, and start plugging the new version of the module/class/control/what-have-you in whenever you touch a certain page.

Rinse, repeat...

Using the D&C method will let you a) start working on new features right away, and b) allow you to incrementally correct issues over a longer period, instead of doing a full re-write. Documenting the corrections at each stage (spreadsheet will do the trick - I'm assuming you are the sole developer), so you will know what you have corrected 2 months from now.

Oh, AND USE SOURCE VERSION CONTROL, if you are not already - that will save many tears, down the road (I'm amazed how many developers at all levels ignore that fundamental). SVC is useful even for solo-developers...

Let me know if I should expound on the above in any way (I tried to keep the answer succinct).

  • 1
    I am doing exactly the same thing. By the way, what is your idea of this code if there is any. Should it be rewritten technically and for better maintenance if you were a PM?
    – TheTechGuy
    Commented Jul 18, 2011 at 15:30
  • Again, solely based on what I am translating from description of OP: From a PM point of view have the dev group address glaring issues that detract from maintainability and hinder new additions (not talking about "BUGS" here - those should be eradicated right away). Once this cycle has started and is well under way, couple of months down the road start a cycle of looking to improve the product technically to future proof the product, allowing simplified & more cost effective upgrade as newer versions of the foundation are invariably published (ie: a new .Net, SQL Server, etc). Commented Jul 18, 2011 at 18:18

Whether or not it is a good idea to refactor all of those areas is partially a business decision since as you say the company is growing. Rather than doing a big-bang refactoring of all of the areas you mentioned it would probably be more useful to do them when you are fixing a bug or adding a new feature in one of the specific areas you mentioned. For example if a new menu item is needing to be added then at that time you can refactor the separate menus into one and remove the absolute positioning from them.

This way you are spending the effort not only to improve the code in the identified problem areas but also showing more "tangible" short-term results to the business (although the refactoring can of course also be a tangible improvement over the long run).

Also, it's good if you can add some automatic unit or integration tests to the areas you are changing to avoid regressions and to aid future refactoring.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.