When making a change to a single table in our app, should we minimize the scope of our change, or follow best practice for css/jsp coding?

Question

My co-worker has been assigned the task of editing one of our Java application's tables. She is almost done, but needs to make one final adjustment to the table - this requires her to add a CSS attribute to a single table cell so that it does not wrap to the next line.

However, she's informing me that 'best practice' is to define TD behavior in our CSS definitions.

Changing our TD behavior rather than an individual cell is best practice for sure, but this app is already in production, and there are thousands of different table cells all throughout it - changing the behavior of our cells now could affect every single table cell in the app - so I'm encouraging her to make the change in just that cell to minimize the scope of her change.

Is my suggestion correct - is it better to minimize the scope of this change, or to follow the best practice and change the attribute in our CSS definitions?

Answer 1

If one makes a change to an application which will cause a three weeks manual test cycle, the person or the team is not "always done", not even close. If that is your situation, then it should be obvious that keeping the change locally is clearly the better option.

However, if you have an automatic test suite at hand with a high test coverage, which can do the testing in less than ten minutes, and it gives you confidence nothing got broken, then you can safely apply the change. Or, if the change breaks too many tests, you can still revert the change using your VCS and look for a different solution.

In reality, however, you might face a situation somewhere in between these two extremes, and it is often a trade-off. Nevertheless you should try to keep your software evolvable, and try to make changes possible in a safe manner even when they affect more than part of your system.

So if your team has no such test suite, the best short-term option is probably to minimize the scope of a change. The better mid or long term option, however, is to build such a test suite, so you can safely apply refactorings even if they have a broader scope. Always minimizing the scope of changes typically leads to a degredation of the code quality, increases the "technical debt", and often ends up in a "big ball of mud" architecture.