Why MaintainJ

Click on tabs below to read the details.

MaintainJ saves effort in different phases of the maintenance life cycle, thereby reducing the overall maintenance costs. The below table and charts provide an estimate of the cost savings. The numbers below are representative and could vary depending on the team's task and developers' experience.

Developers new to a large application will get benefited while performing all the tasks listed below. Developers with good knowledge of an application will be benefited most while tuning, documenting and reviewing junior developers' work.

You might change the numbers in second and third columns to better match your team and see the savings estimate.

Estimated cost savings using MaintainJ

Maintenance Tasks Number of Tasks Per Year Effort per Task (Days) Total Effort (Days) Effort Saved with MaintainJ (Days) Effort Saved with MaintainJ (%)
Bug fixes
Response Time Tuning
To ramp up on a new project

New developers on a enterprise scale Java application would take up to 4 weeks before they start fixing defects and adding new features. This effort is typically spent on understanding the application design and also the many Java frameworks used in the application. Even when a developer is familiar with the frameworks used in the application, developers would often need to spend considerable time to come to grips on a new application.

MaintainJ drastically reduces this effort by showing the runtime interactions between the application domain classes for a use case.

In any enterprise these days, business teams at any point of time ask for more enhancements than the software development teams can deliver. Using the effort savings made possible by MaintainJ, Java development teams can fix bugs in lesser time, add more features in less time and as a whole satisfy more business requirements than ever before.

Consistent use of MaintainJ in maintenance life cycle will result in significant improvement in overall quality because of the below reasons:

Better understanding of the system by developers
Using MaintainJ consistently will lead to better understanding of both the structural and runtime behavior of the system. In addition, developers can quickly assess the impact of a changing a method or SQL on the system use cases.

  • When developers well understand the structural design of the application, the application will have consistent design even after years of maintenance, making it easier to maintain.
  • Better understanding of the runtime behavior like response time, the actual SQL statements executed at runtime, database transaction boundaries, database connection isolation levels, etc. leads to less production issues.
  • The ability to assess the impact of a change better leads to more effective regression testing and a better quality system in production.

If an error occurs in production, developers can locate the bug in minutes as opposed to hours or days
Using MaintainJ's capabilities, bugs can be located in just a few minutes. This will lead to quick correction of the production system ensuring a defect free production system.

There is no apples-to-apples competition to MaintainJ as no other tool currently tries to solve the problem of code maintenance using runtime analysis like MaintainJ does. However, below are the class of tools that MaintainJ is often compared with:

Profiling tools: Some profiling tools can capture the method calls for a use case and visually present the call graphs. Most of the time those call graphs are an afterthought to these tools and don't offer the kind of features that MaintainJ offers. For MaintainJ, the call graphs presented as editable sequence diagrams are the center piece. As can be seen in the demo videos, these diagrams solve various maintenance problems by providing quick way to solve the common maintenance problems.

Static code analysis tools: There are many of these tools, which generate class and static sequence diagrams from source code. They analyze the source code in the hope of extracting the structural design of the application and thereby making it easier for developers to change the legacy codebase. However, this approach is not very successful in helping developers.

Take the typical scenario of a developer who needs to fix a defect in a large application. Most probably, the bug is in one or two classes. If the developer can quickly find the classes and methods to fix the defect, as the changes are mostly local to those classes, the changes won't most damage the structural integrity of the application. None of the current static structural analysis tools in the industry can help the developer to quickly find the components to fix.