Dealing with application redesign

Question

I am working on a project to redesign/ redo an application. The problem is that the old application was written in ASP.net 1.0 and the database is pretty large over 100 tables and 300 odd views.The database handles roles and membership in a very shoddy way. It involves a simple workflow too. The app is pain when it comes to maintainence. I have around 3-4 months to redo the software.

The DB design is not to my liking but looking at timeframe migrating data and DB redesign may make the project go off track.

Anyone ran into this situation before?? Any one has any pointers for me as to how to go about this project??

I would love to get the software up to speed with .NET 3.5 . I am not sure if App redesign would be meaningful without considering the DB

Problem with system: 1. Maintainence and scalability issues. 2. Poor DB design specially in case of user management, the app depends heavily on users and roles etc.

Answer 1

If you don't want to do the database redesign, you could always restructure your user experience(UI). Use an good pattern if you choose to work with webforms then my advise is to use Model View Presenter-pattern or if you know a lot of javascript and html and you don't like the webforms model use the new ASP.NET MVC.

But before you are going to restructe your application you must understand your design pattern you choose.

I'll hope you could do something with this info.

Answer 2

Is your charge to redesign the database or the entire application? Are you on a solo mission or do you have a decent amount of help? Does your company employ any methodology standards (SDLC processes) or are you a maverick IT department?

Four months sounds very aggressive. You'll need to document the requirements, plan, design, build and test every functional component, convert data from the old system to the new system, and possibly set up new environments for all of these scenarios to take place.

The bottom line is this: spend a decent amount of time estimating the work it would take to go through the entire process. If it's four months, great. I doubt it will be. Once you have a documented, detailed estimate of the effort involved, take this to your boss and explain to him how extreme the four-month time frame really is.

If your main concern is whether or not to redo the database, consider the old idiom that a chain is only as strong as its weakest link. The new application will be written in .NET, but would it really make sense to be sitting on a shotty database with a poor design?

Spend the time planning your project, and you'll spend far less time doing the actual development, testing, and re-work that you'd encounter otherwise.

Hope this helps.

Answer 3

It's sort of an old saying that smart data structures and dumb logic beat the reverse every time. See rule 5 in the unix philosophy article. When it boils down to it, every project I've been on where I've had to monkey around with code to fix broken data structures has been a pain.

Short Answer: Re-do the data if you can.

Long Answer: Be pragmatic. If you can save yourself some headache by only re-doing part of the database, do it. It will be more suffering to deal with it in the application logic than at the database level.

Hope that helps!

Answer 4

Database redesign is a huge effort. If you or someone on your team is not an expert in database design and ETL, you could end up with a worse mess than you have now.

However, is it possible to perhaps fix just the one or two worst parts of the database and thus achieve an improvement overall? Look at the worst performing queries to see what is really wrong (not just from your personal perspective of what you dislike but what really isn't working well now). Maybe something less than a total redesign could give you a major performance boost.

If the reason you dislike the database is that it is not truly relational, it is possible you could compromise by putting in relational tables with new names, moving the data and dropping the old tables, and creating views with the old table names that are structured like the current design. (Do not do without a current datbase backup first!!!!) That way you can start to change code to the new more effective design but the stuff you don't get changed will still work until you get to it.

Answer 5

I really don't know the scope of the projects. But 4 months to redesign a system which as 100 tables seem unrealistic. Except ,maybe, if you know the domain very well.

my 0.02$

Answer 6

To add my $0.02, you first have to be clear about why you are doing the redesign, what is the problem with the current software, is it performance, maintainability, better base to extend the product, etc. Then clearly state your objectives for the new product (ie. improve UX, performance objectives, framework, etc.) maybe this will give you a better view of what need to be redesign and what works.