Modularize those old Java apps


News: Modularize those old Java apps

  1. Modularize those old Java apps (6 messages)

    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.

    Threaded Messages (6)

  2. Legacy Code[ Go to top ]

    There is a term used for the crappy part of any software.. Its called Technical Debt!
  3. spot on[ Go to top ]

    Addressing technical debt is exactly what Sidha was getting at. When a senior developer or enterprise architect steps into an organization that already has a lot of technical debt in their legacy Java code (or wakes up one day and realizes how bad their own tech debt has gotten), how does he or she get started on the path to paying the piper?
  4. Technical debt.. blog[ Go to top ]
  5. Technical debt.. blog[ Go to top ]

    This made for some interesting reading. However, it seems like Mr. Maioli's solution always comes back to "use relational programming in the Instant Developer IDE." I don't want to sound overly critical or dismissive because I had never heard of Instant Developer before. But I will. If it sounds too good to be true, it probably is. This is from a couple of years ago, but Lisa Crispin gave a pretty concise overview of technical debt and some advice for Agile teams that need to balance quick sprints and routine maintenance.
  6. Technical debt.. blog[ Go to top ]

    James, as stated in my white paper, I can assure all readers that Instant Developer WORKS as described. This is why more than one hundred Italian software companies use it for their core business products, instead of using eclipse or visual studio.

    I think it is enough to say that Instant Developer performs an automatic real time 100% code refactoring, each time you modify the project, even crossing the boundaries among applications. Does it sound too good? Yes it does, but it is just like that and it really works.

    If any of you would like to know more, why not trying it for free, downloading it from our web site ( Or just skype me at skype:amaioli.

  7. Some code is such monolithic mess that you need to progressively and selectively tear out variable and code at different angles e.g. make new objects, as well as new methods; this is best done by an experienced developer. It also helps to run PMD and FindBugs on the source code to spot the subtle nasties lucking in it. I have had to untangle a lot of complex, nasty rushed consultant code and found loads of bad practices, including unreliable resource freeing, expensive resources not closed, confused interleaved JDBC code, inefficient byte based code for character data, stupid use of new String(), swallowed important exceptions (including InterruptedException!), nulls returned instead of exceptions, no (useful) logging, assumed thread-safe code which isn't, stupid abuse of Swing objects inside and outside the AWT Event Thread, and FindBugs also found some infinite method recursion in long deployed live code. Hashtable, Stack, StringBuffer, and Vector, should all have been marked deprecated by Java 1.5 (they are still used in core SDK libraries and still not deprecated in 1.7, WTF!), and all the Collections.synchronized* methods should have strong warnings attached, because they provide expensive and often unreliable Thread-safety! java.util.concurrent.* should be a lot bigger, because there are a lot of missing concurrent data structures! Most serious code uses some concurrency now and you need to know what you are doing, otherwise you get nasty bugs or performance issues.