# How a Risky Code Change Caused Regressions and Delayed Planned Work

DevFeed: [How a Risky Code Change Caused Regressions and Delayed Planned Work](<https://devfeed.tech/articles/don-t-touch-that-code-19291.md>)

Original publisher: [Read original article](<https://www.codenameone.com/blog/dont-touch-that-code/>)

Author: Shai Almog

Published: 2017-10-17T00:00:00Z

Content type: opinion

Language: en

Sources: [CodeName One](<https://devfeed.tech/sources/codename-one.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [bug](<https://devfeed.tech/topics/bug.md>), [test-coverage](<https://devfeed.tech/topics/test-coverage.md>), [migration](<https://devfeed.tech/topics/migration.md>), [Accessibility](<https://devfeed.tech/topics/accessibility.md>)

Tags: [bug](<https://devfeed.tech/tags/bug.md>), [code](<https://devfeed.tech/tags/code.md>), [migration](<https://devfeed.tech/tags/migration.md>), [test-coverage](<https://devfeed.tech/tags/test-coverage.md>)

## AI overview

The article discusses regressions caused by changing the widely used getComponentAt(x, y) method. Although the change fixed a bug, it triggered more serious problems and had to be reverted. The resulting review delays planned side-menu migration work and may affect the targeted 3.8 release scope.

## Source excerpt

Last week scrolling broke and we had a few relatively complex regressions. This can be traced back to a change we did to the getComponentAt(x, y) method, this change in itself fixed a problematic bug but triggered far worse bugs and we just had to revert the whole thing... So why did we even do a change to a method that's so deep in the code and so risky?