Was System B a re-development of System A?

no. different systems entirely.

All the more impressive :)

Is this a cliffhanger? Do you plan a 'reveal'? I'm dying to know what made the difference.

In our company if System B has 30 bugs and System A has 30 bugs the system with the best quality is System A, because for our management this is the measurement of quality of a system:

Number of Bugs / Lines Of Code

The lower the number the better quality it has.

That's what happens when management doesn't know anything about code.

Check out Simian, it can help identify spot of duplication fairly well..

www.redhillconsulting.com.au/.../simian

RA

So far the metric you are using is meaningless. Lines of code/screens is a non-measure. What do these screens do.

CRUD screens have a few less function points than more complex modeling screens or some such feature.

We need more info sir.

@Rod,

I'm not proposing a metric. There is no science in this. It is just very interesting, and it has me searching for an objective principle in it.

I can see that you are headed somewhere. Would love to hear what you find in terms of functionality differences and architectural differences....

Stay tuned for next episode I hope :)

Are you differentiating lines of generated code here? maybe one of the projects have tones of typed datasets lines that no one has to mantain for example?

Not that i will be pleased to here someone likes to work with that, but at least the designer generated lines don't need to be maintained.

I think we need more information what these systems do, I can't say anything from number of screens, lines of code and 'both are line-of-business applications'.

I've implemented a system, 'line-of-business application', that has about 20 screens - pages, but that were only administration pages (system parameters & dictionaries administration).

Whole sophisticated business logic & background services were generating pdf-s and sending them via email.

20 easy pages, but a lot of sophisticated business code working in a background.

Seriously, I don't get the point of this post. You can have an app with a small number of lines of code and a lot of screens and still have a bad architecture. Maybe you should consider doing a post where you explain something meaningful about both systems and how system B's architecture was superior than System A (and for that matter what the actual architectures are for each). Line count, as mentioned, tells us nothing. Page counts tell us nothing.

In response to "Increased lines of code means increased Total Cost of Ownership", applying SOLID principals generally adds more lines of code. By adding method and class signatures alone, the LOC is increased.

So in a smaller system, a few Monster classes could be less code than the same system created with sound architectural practices. Which would have a lower TCO?

I'd be interested in a metric comparing deployment complexities for the two systems. How many files, virtual directories, xml configuration settings, windows services ectera does each system have?