The story behind MaintainJ as told by its founder, Choudary Kothapalli:
I have been working on Java since 1997. In the first 6 years I was mostly doing design and development and in the last 8 years I was mostly into maintaining large Java applications. In the last 8 years MaintainJ provided maintenance services to 7 different organizations for applications of different scale and complexity.
At each company, the applications are mainly Java, J2EE based - Struts/Servlets/ JSP/EJB/ Spring/ Hibernate/iBatis/SOAP/AJAX/ Portals etc. Nothing very fancy there. Still, with all my experience in Java, I find it very time consuming to track down even simple defects. I usually end up spending lot of time in the debugger.
It would definitely be better to thoroughly understand the code and minimize the time spent in debugger, but it does not happen. Most of the time there is little useful documentation. The core developers who could explain the design are always busy. Good developers always tend to be too busy to have enough time to coach new developers.
Different applications are complex (and difficult to understand) in different ways.
Some applications are just messy. They start as small applications and because they are successful, they evolve into larger applications. As the original design was not intended for large applications, after 3-4 releases, the design becomes messy enough that a new developer would find it hard to understand and maintain.
At one very successful product company, the design was very generic in nature because the primary design requirement was flexibility. That design seemed to work for them. But it was chaos for any new developer. There were good engineers at that company but few were able to crunch down the design to some basic and consistent principles and make it easier to follow.
At another large automobile company, it was complexity arising from huge code base. The original design was good and one result of that was lot of code reuse. Three years after the initial release, it would take many months to make simple changes to the core modules.
The fact is, it is impossible to design the core modules for all the future requirements. And when the core modules are good, applications grow very fast around them. In an enterprise setting, it is impossible to review each line of code and maintain a clean design over the years.
The time and skills will remain a constraint in the software industry for the foreseeable future. Given those constraints, without proper tools, developers will end up taking lot more time than really necessary to understand and maintain code.
MaintainJ is the result of my thinking that there has to be a better way to understand complex Java applications. It is built for and tested on large real-world applications; not some academic or 'Hello World' applications.
Check the blog for MaintainJ related issues and thoughts.
303, 3 Massey Square, Toronto, ON, Canada - M4C 5L5
Ph: 416 686 7494