Bringing Enterprise Framework Upto speed

Question

If a company has developed a framework for doing almost everything their business requires, but has following problems :

1. With evolution and change of ownership the design has degraded. ( Absurd hierarchies )
2. Is not up to date with latest trends in enterprise software development. (Data Sets!!)
3. Too many dependent modules. ( Not interface based, code dependencies, tons of xsd etc )
4. It take a new hire loads of time to catch up because the framework is private to the company.( Bad coding practices in past, lack of documentation, scattered business logic )
5. Not using any well known libraries like (log4net/ CSLA / Spring.net / Drools )

How do you go about doing the following as a Sr. Dev :

1. Convince higher ups the need of a revamp / re-design.
2. Incremental re-design or continuous refactoring ? Best bet?

My biggest concern is how to explain the higher ups that there is a problem with the framework. A sound advice on incremental redesign vs continuous refactoring the framework would be nice too!!

Thanks in advance!!

Answer 1

You'll probably find that those higher up don't care on points 1, 2, 3 or 5. Your best bet is to refactor a small piece at a time. There are a number of similar "how do I convince my boss .... " questions on StackOverflow. I'd recommend reading them all and deciding on what approach you think will work best for your environment

• Similar Question #1
• Similar Question #2
• Similar Question #3
• Similar Question #4
• Similar Question #5
• Similar Question #6
• Similar Question #7

One final thing to remember is that what is important to you is not as important to those above you. I know it sucks but it's the way things are...

Good luck

Answer 2

Unless you convince the management that maintaining and extending the current implementation is more expensive than reworking or redesigning it... you have less chances to do something "officially".

The technical point of view is most of the time in conflict with business point of view. The technical guys try to make the clean, fancy solution. The business guys want to invest less in the technical fancyness, but to be efficient and have the investment returned.

So, if it is not yet the case of high maintenance costs... what you can do is to try to incrementally correct the problems. However, if it is about correcting architectural or higher level design problems... that is something that can't go easy and might affect the entire system.

Changes can be dangerous, specially in case of an old system, with long history, poor design, etc. So refactoring/reworking might introduce new, undiscovered problems, so it is risky.