This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Good to see a book on a systematic approach to do code re-factoring, which I believe is a major activity happening now a days in software.
The quick introduction and the book's content seems to talk about dealing and improving legacy code. So, My question here is - Is this approach or method completely dedicated to re-factoring alone?
Or, are there parts of the approach that can be applied to new code development as well?
Using The Mikado Method is great way to surface dependencies and it doesn't really matter if they are structural dependencies in code or things you need to take care of before something else can be done. I.e what needs to happen before a new feature is complete.
If you use it to 'drive' new features your graph might be a bit more exploratory, change more often and contain some guesswork, but not necessarily so. You can actually be very strict when you develop new features and do a lot of reverting. But usually the code is a bit more forgiving when you add to it.
So the short answer is; Yes, it can be used for new features as well as restructuring and regaining control of a messy code base.