MaintainJ Blog

Check the blog for MaintainJ related issues and thoughts.

Contact Us

MaintainJ Inc.
1006, 9 Crescent Pl, Toronto, ON, Canada - M4C 5L8
Ph: 416 686 7494
email: support@maintainj.com

MaintainJ Story

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 6 years I was mostly into maintenance. In the last 6 years MaintainJ provided maintenance services to 7 different organizations for applications of different scale and complexity.

At each company, the applications were mainly J2EE based - the same old Struts / Servlets / JSP and EJB based. Still, with all my experience in Java and J2EE, I used to find it very hard to understand the applications. Understanding the business requirements takes time but, the time needed to track down a defect was not acceptable. I used to spend lot of  time in debugger to understand the flow. 

It would definitely be better to read the code to get an overall understanding and minimize the time spent in debugger, but it does not happen. Most of the time there was little useful documentation. The core developers who could explain the design were always very busy. When they found time, many of them could not condense the system to a few design principles. The other important reason was time, which was always in short supply.

I have to mention that in spite of my unhappiness over the time I had to spend in understanding the code, our clients were very happy with the results we showed. They are always more than happy to spend a couple of thousand dollars to get a simple defect fixed. It is still so and it beats me. 

Different applications are complex (and difficult to understand) in different ways.

Some applications were just messy. They started as small applications developed by smart developers and because they were successful, they evolved into bigger applications. As the original design was not intended for large scale applications, the design was not consistent as the applications grew. After 3-4 releases, it was hard for a new developer to understand the code. Even old developers would find it difficult to recall something without spending a few hours.

At one very successful product company, the design was complex as the primary design requirement was flexibility. That design seemed to work for them. But it was chaos for any new developer. It was common for new contractors to leave or to be asked to leave in a month. 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 business people always wanted more enhancements than the development team could handle. The original design was good and one result of it 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 very hard to review each line of code and maintain a clean design over the years.

During that time, I always wished to have a tool to quickly generate the runtime sequence diagram for a use case. MaintainJ is the result of my thinking that there should be a better way to understand complex Java applications.