While small changes or localized changes do exist, sometimes the demon is misunderstood for one. What defines a demon then? A formula I like to use is if the change is encapsulated within a small area of the application, a low-level module or one class affecting functionality of just that module or class. The mistake I have seen made is a functionality which is not encapsulated within a confined class \/ module but we feel it\u2019s used only in one or few specific areas being confused with a localized change. Unless there is no way this change can be accessed or affect directly anything outside its scope, it\u2019s not a localized change.<\/p>\n

 <\/p>\n

Quarantine the demon<\/h2>\n

The change must be done no doubt, but can be done in time of peace, not on the 11^{th<\/sup> hour a day before regression. Implement it in the early sprints of a release, so there is time to react and adjust before the deadline hits. Firstly, while implementing you hopefully will not be in a rush and can think through. Secondly there would be time to test issues around just that change and would be easier to identify the cause of bugs we see.<\/p>\n}

 <\/p>\n

A general best practice is to make changes in increments rather than doing the whole big change at once. If you have automation running on UI or API level, that makes things easier. As you push the big change in increments, you get to know right away any outright effects it might have. And if you don\u2019t have automation, I would say first think of doing that, otherwise you can focus manual testing as much possible towards testing the ripple.<\/p>\n

 <\/p>\n

Big decisions take time<\/h2>\n

Like in life big decisions take time not just to research on, but to think about and reflect upon. Similarly, I feel taking time for architectural changes to \u2018sink in\u2019 or internalize takes time. By doubling the resources working on it, it would not get done in half the time. For big changes, I usually start thinking about them ahead of time with my team, so when we do start doing it we have things in perspective and can make a better judgement.<\/p>\n

 <\/p>\n

Care to share what else would you would do to make an architectural change transition smoothly?<\/p>\n<\/div>

<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":13427,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[40],"tags":[],"yoast_head":"\n