80% Code Reuse!

Another project team at my company was developing a set of 10 or so applications.  This was the team members' first attempt at using .NET in a production application.  Everyone had received some sort of training, even if it was only a few days.  Previously, all applications of this type were created on a one-off basis.  This team, under the technical leadership of the project manager (see this Wiki for the pros and cons of managers coding), started out by constructing a .NET application that contained most of the base functionality.  So far, so good.

The project team then proceeded to branch the files into 10 separate copies to finish development.  We use Visual SourceSafe for version control.  It is not great, but it works and it's free with Visual Studio.  Now, whenever there is a change to a common file, it must be changed in 10 different locations.  The files are not shared, since there was a need to customize for each application.  Despite this, the project manager claims 80 percent code reuse.

Or, 250% Bloat

Assuming each application was 10,000 lines of code (LOC) total, including the common code (I'm sure it is more, but this will do for demonstration purposes), the suite of applications totals 100,000 LOC.  Not bad.  Also assume that the project manager is right, and there is 80 percent code reuse, if it were not duplicated.  That would mean that there should be a total of 28,000 LOC:

• 10,000 LOC * 80 % code reuse = 8,000 LOC for the common app
• 10,000 LOC - 8,000 LOC = 2,000 LOC for each unique app * 10 apps = 20,000 LOC
• 20,000 + 8,000 = 28,000

Instead of achieving something monumental (80 percent code reuse is ridiculously high and would imply productivity the likes of which my company has probably never seen), this has actually deployed 72,000 duplicate LOC that need to be maintained.  This is roughly 250 percent greater than the size of the completed suite of applications!

The Real Purpose of Development

The real purpose of development is to have an operational system, not to achieve code reuse, impress people with the size of the applications you are building, etc.  I am not saying that the project manager was doing that, but I do not think the focus was on the true end goal.  The Microsoft Solutions Framework calls it a product mindset, XP, SCRUM, and other agile approaches mark progress only when the system is working.  In the end, your objective as a developer is not to write lines of code (or function points or whatever else a company myopically tries to measure you on) but to NOT write lines of code.  The less LOC there are in the world, the less time we will spend on maintenance, the more quickly we will develop new products, and the more interesting work we can accomplish.