They say that the first step in solving a problem is admitting that you have one. With that in mind, you might start by generating a dependency graph that illustrates the vast tangle that is your current code base. Good tool to generate dependency diagram? is a few years old but contains some pointers to tools that can help create such graphs. I'd go with one great big, ugly graph that shows as much as possible to drive the point home. Talk about problems that result from too many interdependencies and maybe throw in a line from Buckaroo Banzai:

You can check your anatomy all you want, and even though there may be normal variation, when it comes right down to it, this far inside the head it all looks the same. No, no, no, don't tug on that. You never know what it might be attached to.

From there, introduce a plan to start to straighten out the mess. Break the code into modules that are as self-contained as possible. Be open to suggestions as to how to do that -- the folks you're talking to know the history and the functionality of the code better than you do. The goal, however, is to take one big problem and turn it into some number of smaller problems which you can then prioritize and start to clean up.

Some things to focus on:

• Create clean interfaces between modules and start to use them. Old code may, of necessity, continue to not use those nice new interfaces for a while -- that's the problem you're starting to solve. But get everybody to agree to use only the new interfaces going forward. If there's something they need that's not in the interfaces, fix the interfaces, don't go around them.

• Look for cases where the same functionality has been repeated. Work toward unification.

• Remind everybody from time to time that these changes are meant to make life easier, not more difficult. Transition can be painful, but it's for a good purpose, and the more everybody is on board the faster the benefits will come.

They say that the first step in solving a problem is admitting that you have one. With that in mind, you might start by generating a dependency graph that illustrates the vast tangle that is your current code base. Good tool to generate dependency diagram? is a few years old but contains some pointers to tools that can help create such graphs. I'd go with one great big, ugly graph that shows as much as possible to drive the point home. Talk about problems that result from too many interdependencies and maybe throw in a line from Buckaroo Banzai:

You can check your anatomy all you want, and even though there may be normal variation, when it comes right down to it, this far inside the head it all looks the same. No, no, no, don't tug on that. You never know what it might be attached to.

From there, introduce a plan to start to straighten out the mess. Break the code into modules that are as self-contained as possible. Be open to suggestions as to how to do that -- the folks you're talking to know the history and the functionality of the code better than you do. The goal, however, is to take one big problem and turn it into some number of smaller problems which you can then prioritize and start to clean up.

Some things to focus on:

• Create clean interfaces between modules and start to use them. Old code may, of necessity, continue to not use those nice new interfaces for a while -- that's the problem you're starting to solve. But get everybody to agree to use only the new interfaces going forward. If there's something they need that's not in the interfaces, fix the interfaces, don't go around them.

• Look for cases where the same functionality has been repeated. Work toward unification.

• Remind everybody from time to time that these changes are meant to make life easier, not more difficult. Transition can be painful, but it's for a good purpose, and the more everybody is on board the faster the benefits will come.