-
Notifications
You must be signed in to change notification settings - Fork 4
/
aboutus.html
80 lines (70 loc) · 3.49 KB
/
aboutus.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
<HTML>
<BODY>
<h1>MaintainJ Blog</h1>
<p>
Check the <a href="/blog">blog</a> for MaintainJ related issues and thoughts.<p>
<h1>Contact Us</h1>
<p>
<strong>MaintainJ Inc.</strong><br>
2611, 5 Massey Square, Toronto, ON, Canada - M4C 5L6<br>
Ph: 416 686 7494 <br>
email: support@maintainj.com</p>
<h1>MaintainJ Story </h1>
<p>
The story behind
MaintainJ as told by its founder, Choudary Kothapalli:</p>
<p>
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.</p>
<p>
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.
</p>
<p>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.</p>
<p>
Different
applications are complex (and difficult to understand) in different ways.</p>
<p>
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.
</p>
<p>
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.</p>
<p>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.
<p>
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. </p>
<p>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.
<p>
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.
</p>
</BODY>
</HTML>