Back from holidays, back to work.

I’ve got some ideas for this new season, but let’s just start with a little ‘quiz’.

Imagine that you are asked to categorize an application acccording to its size, number of lines of code (LOC) or number of objects. What is your estimate of a small application? When do you say that an application is big? What are the numbers for a ‘monstrous’ one?

This question may arise quite frequently and it is not so easy to asnwer precisely and with certainty. For instance, you are asked ‘Are 200 000 lines of Java code a large application?’ or ‘500 Cobol programs, is it big? ‘. It may be your boss or a salesperson to which a customer requests a reference of ​​costs to support the maintenance of an application of this size. This can be a manager in your company who wants you to do an assessment of the quality of his application but would like to know how much effort or how much time is needed to analyze this code.

Note that I am not talking of the effort of development or maintenance of an application nor of programmer productivity. Some people consider the LOC metric is a ‘malpractice’ and I totally agree that it should not be used to measure productivity, effort or the level of functionalities inside an application. But when I analyze code, I like to know if it will be a small application or a big monster. If not for me, just to answer the customer who would like to get an idea of an agenda or a price. All Quality consultants get asked this question.

Here are the values I used:

Application size (KLoc)

For example, a J2EE application would have :

• A low size below 50 000 LOC.
• An average size between 50 and 200 Kloc.
• An high size between 200 and 400 Kloc.
• A very high size above 400 Kloc.

Over 1 million lines of code, I believe that a J2EE application is a monster, that is to say non-standard. Note: in most cases, it will be not a single application, but rather a system composed of multiple modules. But whatever the name, if this code is in the hands of a single project team, then this team is facing an Everest. With the specific problems you get to manage such a mountain of code.

The table below shows the same evaluation, but based on the number of objects.

Application size (number of objects)

Very often, the number of objects is the only known information: few clients or project managers know the number of lines of code of an application. And this information can be misleading.

For example, you get to analyze an application with 800 Cobol programs, but the person in charge to perform this extraction also delivered you the whole 20 000 Copy-books present on the mainframe (as he does not know which Copys are used by this application). It looks over-monstruous, but there are probably only 2 or 3% of the Copy-books that work with this application. It is thus of average size. Now, if you decide to analyze all the Copys, then you have a big work ahead for a result that has not much sense in terms of assessment, since the scope of analysis does not match an application or the work of project team.

Sometimes you have a J2EE application with a lot of JSP pages or a large number of XML configuration files (especially with some frameworks) and few business classes. Again, the number of objects or lines of code will not be really representative.

I had many discussions on this topic with professionals performing code quality assessments, and if we often agree on figures close enough, we all know that this indication can vary considerably as shown in the previous examples. But sometimes you have to answer the question ‘Is it a big application?’ without not so much information.

And you, how do you categorize an application?