tag:blogger.com,1999:blog-13831777.post7369933548452404131..comments2024-03-27T09:37:53.071-04:00Comments on Coaching Agility: Refactoring and the Law of Unintended ConsequencesDamon Poolehttp://www.blogger.com/profile/16561311551267979837noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-13831777.post-82507507497690688822007-06-21T19:51:00.000-04:002007-06-21T19:51:00.000-04:00The impact analysis can be as complicated or as si...The impact analysis can be as complicated or as simple as you deem appropriate, I'm just suggesting that you do it. I'm a huge fan of writing automated tests for all changes, a practice included within TDD. However, I also know that getting all of your tests to pass does not mean that you have removed all risk of unintended consequences. TDD reduces risk, but does not remove it entirely.Damon Poolehttps://www.blogger.com/profile/16561311551267979837noreply@blogger.comtag:blogger.com,1999:blog-13831777.post-22881516985638075112007-06-05T05:09:00.000-04:002007-06-05T05:09:00.000-04:00Instead of investing an effort on such complex imp...Instead of investing an effort on such complex impact analysis you should invest in Test-Drive-Development (TDD); you will not refactor your component unless you have an automatet test in place and your component (and system) pass all your test before beginning of refactoring; then after every incremental refactoring/improvement you will run the whole bunch of tests again, etc.Unknownhttps://www.blogger.com/profile/09528354660931905761noreply@blogger.comtag:blogger.com,1999:blog-13831777.post-44673258046047569722007-05-10T08:21:00.000-04:002007-05-10T08:21:00.000-04:00What about prioritizing the changes by the impact ...What about prioritizing the changes by the impact of their effect? Are you looking for changes that will have a non-linear positive effect as those would be the most "profitable" or would those also be the most risky?John J. Wallhttps://www.blogger.com/profile/06102232592800229386noreply@blogger.com