I am doing a code review for a commercial software system. I noticed that some user's story and even sub-tasks when are implemented they result in a large code commit and usually end up in changing tens of source code files (java classes, javascript files, HTML, etc)

I expect that when someone implements a subtask or a single user story will only require changing few components. Sometimes the commit can have up to 60 files changed.

Attached a screenshot to illustrate the case enter image description here

another example

enter image description here

Note: I don't think my question is a duplication of I changed one method signature and now have over 25,000 errors. What now? In my case, I am trying to understand if the software suffers from high coupling or not by looking at the cost of code review. Why changing the behavior of a user story requires many changes in the source code?


2 Answers 2


Is this an indicator of high coupling?


Sometimes this is an indicator of high coupling because when one thing changes, it cascades along, impacting a bunch of other things.

Sometimes it's an indicator of loose coupling because when you want to do one sizable thing you need to touch all of the different responsibilities necessary to provide a cohesive feature to end users.

Full stack features tend to make this worse, since you get to do the front end, and the back end, and the tests for each, and the contracts for each.

Java tends to make this worse with its idiomatic BlahBlahServiceProviderFactory style need for classes to do everything.

Your need for internationalization will tend to make this worse, since you'll need to separate out resources from the code.

And frankly, code reviews tend to make this worse, since people want to avoid the overhead of the review, and reviewers want cohesive features to review, not small slices with things still in progress.

So while broad check-ins can be a sign of coupling, they're more often a practical side effect of business features necessarily crossing module boundaries.

  • OK, the system has several other components. I think I can compare the cost of code review and code change among the other components written by other teams or developers to see if the cost is similar or not. I personally, develop in Java and other languages but I do not have this large check-in pattern in my code. Although I wrote small micro-services. What do you think?
    – Ubaidah
    Commented Dec 27, 2016 at 21:24
  • This is why loose coupling is often a red herring. Tight coupling actually has some advantages. Solutions in Visual Studio are pretty much as tightly coupled as software gets, so loose coupling in those projects really only has meaning at software layer boundaries (where you can use interfaces or even strings to ease the problem). Commented Dec 27, 2016 at 21:48

EDIT: I wrote the following response under the mistaken read that the asker wanted to know whether the widespread use of a Java method by other components was an indication of tight coupling between that method and the components using it (in which case the answer is no, as I replied below).

Now I see that the asker was trying to infer the likelihood of tight coupling in the system on the basis of the review.

The following answer addresses only the former case, but I'm leaving it up because I think it's still relevant to that part of the question.

I wouldn't consider this tight coupling. The signature of a method is part of its specification. If I changed String::length() to String::length(boolean derp), it would probably break a lot of Java code out there. You can't expect that changing a method won't cause a lot of errors.

All this indicates is that this method is widely used. If you need to change what the method does, then in most cases you should be writing a separate method, not modifying a method that is already in wide use.

  • 1
    +1, but I kind disagree with you. Because, this is not the case here. if you look at the number of code changes added vs removed in each commit.
    – Ubaidah
    Commented Dec 28, 2016 at 21:28
  • @Ubaidah I think I may have misinterpreted the question somewhat. I agree with the current top answer, in that case. I'll clarify my response a little. Commented Dec 28, 2016 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.