Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I had two web applications with similar settings as you. I stopped using FindBugs and Checkstyle as they showed more than 10.000 problematic points. The applications used JDBC level data access, JSP for presentation and a custom framework for request dispatching. Luckily for me, these low level settings allowed me to do the extensions and fixes on medium difficulty. During the 3 year project, only about 20% of the original code remained as it were. Sooner or later everything else needed to be either changed, replaced or removed (and finally I was able to use FindBugs and Checkstyle).</p> <p>We too faced the dilemma of complete rewrite. However, there were several factors against it:</p> <ul> <li>Not sure customer will pay for a complete rewrite.</li> <li>The lack of functional and technical documentation makes it risky to do the complete rewrite.</li> <li>Manhours to fully understand the complete application was too high. Customer wanted the requested changes sooner.</li> <li>The users where customed to the presentation and page behavior. It seemed hard to convince users to use a new interface for old functions.</li> <li>If we do a complete rewrite, we need to provide complete documentation. For update, we needed to document only our part.</li> <li>It is hard to convince the management (own and the customer's) of a rewrite if the program works (more or less)</li> <li>The company had its own PMD rules and the code didn't pass. It was simpler to argue that it is enough the new parts pass the test.</li> </ul> <p>It boils down what you want to do actually. </p> <p>Do you want to rewrite, despite the complexity?</p> <ul> <li>Put emphasis on the code bugs. Large pie charts with lots of red is convincing.</li> <li>Explain the program properties and how they don't fit into the corporate vision.</li> <li>Show enhancement options beyond the current requirements and describe how the current version is not up to the challenge.</li> <li>Do interviews with the real users. They might point out important problems with the current version.</li> <li>Be cheap but a good estimator. You might delay some costs till the maintenance phase.</li> </ul> <p>You don't want to rewrite?</p> <ul> <li>Put emphasis on the cost, especially the manhours required from the customer to re-test everything.</li> <li>Point out the potential trouble of breaking functionality.</li> <li>Ask for a full-time document writer.</li> </ul> <p>If you want to taste the code, try to add the Hello World! function/screen to the application. That tells how hard and how fast you can implement new things.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload