Limits of Modularity
I recently listened to episode #114 of iPhreaks about modularity with Samuel Giddins.
There’s a key sentence in there, around 3:40: “Things can go wrong even if you are doing the right thing”. A while back he forgot to update a dependency and Cocoapods stopped working, even if all tests were passing. Debugging was a bit complicated.
Modularity is drawing imaginary lines. If you are building an iOS app you are probably adopting an MVC model. I assume your code is organized into folders like “Model”, “Views”, “Controllers”, even if you shouldn’t. Let’s suppose that for a specific table view you want to adopt an MVVM approach. Where do you put files? Are ViewModels views or models?. Are they sitting on the border waiting for you to decide?
I am not saying modularity is useless. Indeed, it saved me a lot of time in the past. When I joined ongoing projects modularity helped be (and my project managers) to create a sandbox for me. I had a test suite, I had a “territory” (e.g. the model) and a list of tasks. It was crystal clear.
It gets more complicated in the “previous developer is busy and my app doesn’t work” scenario. You open the project and you see 120 files. Obviously the documentation doesn’t exist or is outdated :) Where do you start? By digging, and digging and digging.
Modularity is needed, especially in big teams, but it’s not the panacea for the perfect project. Two are the weak spots that I saw many times: debugging and onboarding new developers on the team.
I think the most interesting point is mentioned in the podcast, around 24:30. Paraphrasing: whenever making a change takes too much time you probably went too far with modularity.
Give it a listen, many relevant topics are mentioned.