According to IBM, 50%-90% of a developer's time is spent reading, deciphering, and understanding the existing code. When a developer is introduced to new code that number is way up near 90% and the developer becomes more used to the codebase it comes back down around 50%. But half of all developers' time is still spent thinking about the existing code rather than the new code.
Experienced enterprise architect Vineet Sinha explained in his EclipseCon presentation that it's tempting to try and start from scratch to avoid the confusion of existing code and produce new features quickly. However, by making small, incremental changes that each deliver some value, Sinha said developers can build momentum without getting too caught up in infrastructure rewrites.
According to Sinha, less than 30% of the codebase is likely to be business logic and everything else is infrastructure, which might be tightly coupled to the business logic in ways that aren't immediately apparent. Rewriting costs can run from eighteen to forty-five dollars per line of debugged code. When thousands of lines of infrastructure are involved, debugging costs can rack up quickly.
Necessary rewrites must be done incrementally and considered carefully.
Sinha provides some best practices for increasing modularity in legacy Java applications. First, start off with a small solution that works, then build from there. Don't try to fix every problem in the first run. Just focus on one. Make sure that your new solution works without breaking anything else. Schedule time to fix bugs into every project. Sinha recommends setting time for each team or individual to focus on fixing code either at the start or the end of each feature push.
It's also important to focus on what's already implemented over the features that you plan to implement. This is one way to help protect against feature creep. "Initial decisions should be based on the code that's sticking around, and there should be a lot of code sticking around," says Sinha.
Avoid building new features that are based on what you think the codebase will be when version 2 comes around. If your current architecture includes too much tightly knotted spaghetti code, Sinha suggests creating a simplified model of the current feature set, but the simplified model is of "the features you have now, not the features you think you want or the features the business folks might want.
Are you working on legacy Java applications? Let us know what you think about modularity in Java. You can find me on Twitter @TTJDenman.