http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Re: . The database is also not well designed and normalized. And, changing the database means every think cascades from there. Could you restructure your data base and create view that replicate the old database design and the old apps/stored procs just point to the views. http://ayende.com/3418/obsolete-in-isolation#comment22http://ayende.com/3418/obsolete-in-isolation#comment22Thu, 17 Jul 2008 03:24:02 GMTWhy couldn't you compromise -- come up with what you what the system to look like and start slowly refactoring and TDD/unit testing your way towards that? This way your new stuff is solid and your old stuff is still usable and slowy progressing (slouching) towards decent as you merge your improvements in. http://ayende.com/3418/obsolete-in-isolation#comment21http://ayende.com/3418/obsolete-in-isolation#comment21Tue, 15 Jul 2008 15:34:06 GMTI dunno, it's a tough call. Often, our tendency is to re-write from scratch because we don't want to deal with someone else's problem. (Incidentally, politics has the same problem when a new government is elected.) But we are also throwing away a lot of bug fixes and minor enhancements by starting over. Yes, you can't save every project but we should ask ourselves, "Do I want to start over because it'll be cheaper for the business? Or because I don't like dealing with the code?" http://www.joelonsoftware.com/articles/fog0000000069.html http://ayende.com/3418/obsolete-in-isolation#comment20http://ayende.com/3418/obsolete-in-isolation#comment20Tue, 15 Jul 2008 13:54:23 GMTThe brownfield projects a have come across usualy have grown fat, because it was easier to add the functonality to an existing application. So the application has several more or less related functionality all wrapped together in a nice spaghetti dish. I usually break down the application to more manageble pices, one by one. Move the database tables related to the functionality and provide an interface (database level SP/View or some sort of remoting) for the old application. Then Im free to move towards more testable code, because I dont have an entire application dragging behind me. An example could be a CRM application. It consists of many reponsibilities. GUI, Mail and Calender to Exchange, Binary Documents etc. I could then move the Mail and Calendar service tables and code to a new application, and provide acces to it via a SP or a WebService. From there on I could apply sound OOP principles to the code and it could move forward in its own pace, not dependent on the main application - exept if the interface change. http://ayende.com/3418/obsolete-in-isolation#comment19http://ayende.com/3418/obsolete-in-isolation#comment19Tue, 15 Jul 2008 10:02:36 GMTThe book 'Working Effectively with Legacy Code' by Michael Feathers is worth a read. ISBN 978-0131177055 http://ayende.com/3418/obsolete-in-isolation#comment18http://ayende.com/3418/obsolete-in-isolation#comment18Tue, 15 Jul 2008 07:56:55 GMTWe're practising this to a limited extent on our product - All our newer code has fantastic and well designed test suites. Our older code, however, is not so blessed. And there are over 10 million lines of it. The nature of the project, is much like device drivers (financial transaction processing integrating with various acquiring instituations each with their own quirks and a working - term used loosely - and stable body of code built up over years of integration and moving from spec version to spec version, supporting new features such as encryption / chip cards). http://ayende.com/3418/obsolete-in-isolation#comment17http://ayende.com/3418/obsolete-in-isolation#comment17Tue, 15 Jul 2008 06:43:08 GMTI think it would be good to see a follow up post on how to sell it to pmo, as people are *understandibly* reluctant in rewriting something that already works. http://ayende.com/3418/obsolete-in-isolation#comment16http://ayende.com/3418/obsolete-in-isolation#comment16Mon, 14 Jul 2008 23:55:04 GMTWhile (aiming for) rewriting an application might be worthwhile once in a while, I don’t think it pays off rarely as often as most developers would like to think. Sure it’s more fun/efficient to write code for an application based on an architecture you happen to like and know well, but will it save your employer so much time and resources that it all-in-all will be less expensive than maintaining the existing application? Do you have some basic quantifiable data that a decision can be made on, or is it just a hunch or wishful thinking? (The Valence effect... http://en.wikipedia.org/wiki/Valence_effect) Among many things, you’ll need to consider: The total future need of maintenance, the kind of maintenance, etc. Maybe the application won’t change much in the future. Ask the business manager, not just the old dev. Could you study and analyze the current application, so that you at least can develop *fairly* risk-free and time efficient? It might not be nearly as fun, but could you? Could someone else? Is the added complexity worth it (which is true until everything has been rewritten)? Does everyone involved agree? The other developers? The DBA? The QA? Is Oren Eini on your team? Most teams aren't that lucky. And so on. It’s hardly ever a clear-cut decision. Also, one thing that I have observed over the years is that young developers tend to want to rewrite pretty much everything they haven’t written themselves during the last two years or so, whereas seasoned developers rarely want to change any more than what’s absolutely necessary. You might have a different experience, of course. http://ayende.com/3418/obsolete-in-isolation#comment15http://ayende.com/3418/obsolete-in-isolation#comment15Mon, 14 Jul 2008 23:33:19 GMTMigrating a schema in sql server is pretty easy with linqpad... http://ayende.com/3418/obsolete-in-isolation#comment14http://ayende.com/3418/obsolete-in-isolation#comment14Mon, 14 Jul 2008 23:09:53 GMT> it needs to be scraped and re-built. I would say that it doesn't. Mark the bad ways as [obsolete] and deal with them appropriately. As long as you have a right way of handling things at a certain point, there is little issue with that http://ayende.com/3418/obsolete-in-isolation#comment13http://ayende.com/3418/obsolete-in-isolation#comment13Mon, 14 Jul 2008 22:35:41 GMTBob, If it was easy, they would do it in Access. ETL isn't really hard, and having two DB is generally not a problem, you aren't running two different servers, just two DB in the same server. You could even do it with the same DB, if you kept different schema. http://ayende.com/3418/obsolete-in-isolation#comment12http://ayende.com/3418/obsolete-in-isolation#comment12Mon, 14 Jul 2008 22:34:27 GMTJosh, Don't bring in anything that is painful to use. If you have a public SDK, keep it around, wrap that in integration tests, and start adding you functionality on the sidelines. Bring in new API, and keep the old SDK as legacy only http://ayende.com/3418/obsolete-in-isolation#comment11http://ayende.com/3418/obsolete-in-isolation#comment11Mon, 14 Jul 2008 22:24:32 GMTI joined a project like this a year ago. I there is too much business logic in the UI, well you are pretty screwed. If there is a decent amount of code in something resembling objects you are in a much better spot. Here is the approach I took: take what you can from the non-ui objects and wrap it in a service layer. You might have to deal with some threading issues, but you can run services single process / single thread or fix them as they come with simple locking. By wrapping existing functionality in a service layer, you don't have to throw it out, but you can reduce it's impact on code going forward. When you have time to start replacing code, you only have to replace the things behind the service contract, but at least now you can proceed one step at a time without rewriting the whole app before adding a line of new functionality. http://ayende.com/3418/obsolete-in-isolation#comment10http://ayende.com/3418/obsolete-in-isolation#comment10Mon, 14 Jul 2008 21:28:59 GMT@Torkel, I have the exact same problem. :D I worked on a system that was always due in the next two months. After two+ years of this, it has literally 3 ways to do things. My problem is that I am still having to maintain it and cannot convince the powers that be that it needs to be scraped and re-built. How do you convince the customer/manager/boss whatever, that the cost maintaining a system like this is much more expensive than scrapping and rebuilding it? http://ayende.com/3418/obsolete-in-isolation#comment9http://ayende.com/3418/obsolete-in-isolation#comment9Mon, 14 Jul 2008 21:24:32 GMT>Use ETL processes to sync the data between the DBs, don't share the DB between the applications Ha ha... you do realize that is ALOT harder said than done. This will also require all of our customers to run two databases (or even if all the tables are in one database) and some type of sync daemon. I will give this some consideration, but this will add alot of overhead to the project. Although we will need to ETL to move to the new database anyhow... it is the ETL to go from new to old that will add the overhead. BOb http://ayende.com/3418/obsolete-in-isolation#comment8http://ayende.com/3418/obsolete-in-isolation#comment8Mon, 14 Jul 2008 21:24:05 GMTThis is pretty much the way I handled a previous project. The only problem was that I during 3 years of constantly adding and changing features the system had 3 ways of doing things, "the old old way, the old way, the new way" :) There was never enough time to refactor the application to the new design and way of doing things (NHibernte, IoC, TDD), although in the end I was able to convert all data access to go via nhibernate entites and repositories using NHQ :) http://ayende.com/3418/obsolete-in-isolation#comment7http://ayende.com/3418/obsolete-in-isolation#comment7Mon, 14 Jul 2008 20:48:38 GMTok, so imagined a winforms app that runs entirely on a core framework enterprisey beast. The business logic is somewhat separated from the UI but has infected the UI in many areas. The core framework is not testable with unit tests because the whole framework needs to be warmed up and logged into a sql backend, which also contains a large amount of business logic. There is lots of use of Oren's favorite access modifier "internal", and there is a management stipulation to not break the public SDK which is obviously exposed with public methods. How in the world do you make this testable? I've tried... can't mock it, and the entire very large database needs reset/built each time you want a single test run in isolation. We could start new project(s) and implement features in there, but those would be expected to support the SDK. It would also require porting/copying large amounts code to support the data access for each feature in the new project. This is a shipping product with major releases every 12 months. It's a real spaghetti code at a suicidal pace. sry for the long comment. http://ayende.com/3418/obsolete-in-isolation#comment6http://ayende.com/3418/obsolete-in-isolation#comment6Mon, 14 Jul 2008 20:19:14 GMTThe above said, I am more and more tempted all of the time to nuke the legacy code from the trunk and instead require that developers look back into the branch when they need or want to see how something was done on it. We have the luxury of doing this because we are still shipping entirely from the legacy branch until late this year but I can easily imagine situations where legacy-on-branch, greenfield-on-trunk isn't quite so doable for a lot of projects out there. http://ayende.com/3418/obsolete-in-isolation#comment5http://ayende.com/3418/obsolete-in-isolation#comment5Mon, 14 Jul 2008 20:00:19 GMTSame on my current project. The legacy code still exists on a branch and is still maintained when necessary (bug fixes only),. The legacy code also still exists on trunk but only as a source of code that we can move into our new structure and bring up to snuff when we touch that area of the system. http://ayende.com/3418/obsolete-in-isolation#comment4http://ayende.com/3418/obsolete-in-isolation#comment4Mon, 14 Jul 2008 19:58:13 GMTI've been involved on a project, a large B2B website, that it's first incarnation was a quick hacked webforms with some generated DAL and tons of SProcs. as you said - every new feature was built as a MR controller/views + Repository/NH/AR data access + service layer, all wrapped in Windsor. slowly the services and repositories started to propagate into the WebForms, and on any major update to a WF part, it got rewritten into a MR chunk of code. About a year ago it was about 20% of MR/IoC and 80% WF/Sproc/StaticLogicClasses nowadays it's 95%/5% in favour of the good stuff. hoora http://ayende.com/3418/obsolete-in-isolation#comment3http://ayende.com/3418/obsolete-in-isolation#comment3Mon, 14 Jul 2008 19:35:26 GMTObsolete the DB as well, I would suggest. Don't let legacy stuff hinder you back. Use ETL processes to sync the data between the DBs, don't share the DB between the applications http://ayende.com/3418/obsolete-in-isolation#comment2http://ayende.com/3418/obsolete-in-isolation#comment2Mon, 14 Jul 2008 19:29:15 GMTGee.... it's like dejavu. I have the same exact situation. As the architect it is my job to figure out how the ideal architecture would look and then how to get there. So, I have the same basic thought... start from scratch. But, how do you do this with the database. The database is also not well designed and normalized. And, changing the database means every think cascades from there. Most access is done with SP's... so I figured I could refactor the db by changing the tables and modifying the SPs to work with the new schema so that old stuff will still work. Also, I am looking at moving to Silverlight for the UI rather than HTML. But, I don't think they are going to be happy with some Silverlight UI and some the old hodgepodge IE6 only UI. Heck, any ideas anyone have would be gladly accepted. Thanks, BOb http://ayende.com/3418/obsolete-in-isolation#comment1http://ayende.com/3418/obsolete-in-isolation#comment1Mon, 14 Jul 2008 19:00:21 GMT