Well, I've let you sweat for awhile after my post on taking ownership of an existing application, but before the criers hit the streets with the news that I'm an out-of-control rouge who mangles any code that he touches, let me clarify just a bit.

The point of the post was *not* to advocate tearing though your next project restructuring assemblies and changing naming conventions.  In fact, I'll say with certainty that it's an *extremely* rare situation in which this particular approach is appropriate.  I'll be willing to wager that nearly any existing application that you touch will either be being worked on by other developers, it may already be in production, or it may have been though a QA cycle.  Even if the existing code isn't great, in any of these senarios, wholesale or drastic architecture or code changes will cause more problems than they solve.  I guarantee it.  The point, if I may be so bold as to finally get to the point, is that if you're going to be working extensively on an existing application, it's worth taking the time to think about what you can do to best become intimate with it, to take an ownership in it, at least in the pieces of it that you'll be working with.  That way, when you *do* start to add new code, or modify existing code to meet the new requirements, it will fit with the existing application and strengthen it instead of fighting against it and making it brittle.  And that, my friends, is the point.

Sponsor