The Old Joel on Software Forum: Part 4 (of 5)

"Serious" LOC

I am planning a huge migration project; and my boss ask me to include a LOC estimation, "Just to see if we are missing something"...

Before we start: I don't believe in LOC method.

But don't want him telling me latter "I told you that you were underestimating..."; so I will make him happy and make his dream come true.

This project history is: This is an EFT Banking package, bought 10 years ago, originaly is 300K LOC, and it has been heavily modified (200K LOC of increment). It's a C application.

Our target is a different package (at architecture only, since a "balance inquiry" is always more or less the same); on a different platform and also we will use C. And we'll to re-apply many of the modifications in order to keep the same functionality from the end user point of view.

So: Similar packages, similar programming language, similar functionality, quite skilled team with many years of experience.

Since we are planning to start with a very serious documentation, design and programming specification stages before we "launch" the code editor... My estimation of LOC per day per programmer is between 100 and 150 (try to figure that the programmer, will only have to write the lines). After that, comes a testing almost as big as coding.

Reading here some related topics, I've seen some statements saying that "industry standard" is close to 20 LOC per day...

I'm really far away from that... So:
1- Am I crazy and my boss was right?
2- Those "LOC standards", includes all project (e.g, analysis, design, testing)?
3- Both?

Thanks a lot!

Alec Yetitu
Thursday, February 26, 2004

To make any sense of LOC (and even then I doubt there's much sense in it at all), then you have to have some fudge factor as to what 1 LOC means.

If its in C++ its likely to be more expensive in resources to produce than a LOC in VB even if it appears to achieve the same thing, assigning a value to a variable.

If its an API call then the cost is going to be higher because you have to find out what the API call is, learn the API and so on, and possibly cost less because using the API call effectively replaces n LOC of your own. If the net effect is less then you call it .5 LOC or something similar.

If the language you're migrating to is quite different to the source language then your LOC may well be more than twice the cost it may not even be possible to have a 1 for 1 translation that makes any sense.

If its a migration where you can get the code running on the minimum amount of changes then I'd concentrate on the interfaces rather than the actual code. Use shims on the interfaces to convert from old to new and then replace the old as needed, or not as the case may be.

Simon Lucy
Thursday, February 26, 2004

In my most recent contract I wrote 3700 LOC of C++ (measured by counting ';' in *.h and *.cpp files) in 4 calendar months. This was all new code (no copy-and-paste), included the time to write a requirements document, a detailed design document and test plan, settle in to working with new people (a new employer), use Linux for the first time instead of Windows, and to do developer testing.

I think that's 3700 LOC / 62 days = 60 LOC / day.

Of these 4 months, approximately 1.5 months were spent doing coding and developer testing, and 2.5 months doing requirements and design, so if you include only the coding days then the LOC / day would have been closer to your 150 LOC / day estimate.

I'm not mentioning a 5th month, which I spent with the integration and QA teams after 'code complete'.

In the last years of my previous job my average might have been below 60 LOC / day (i.e. closer to your 20 LOC / day average) because there I had a more significant overhead (managing, talking to customers, debugging a running system, training, big company 'process' overhead, and so on).

Christopher Wells
Thursday, February 26, 2004

Alec,

If I were doing the estimate, I'd try to find out how many developer years went into the 200K LOC of changes. Then I'd assume that I have to make the same changes again and figure out LOC per developer-day for my organization.

Its a rough estimate. Some things will be faster now -- you probably have a better understanding of the problem domain now. But some things will take longer -- you have less experience with the new architecture.

Good luck

Steve S
Thursday, February 26, 2004

Industry standard at one point was 10 LOC per day. You don't actually write 10 LOC/day. You write about 50-60 LOC/day for the 2-3 months of heavy-duty work, then you write very little in the ramp-down, testing, ramp-up, research phases of the next project.

The average comes out to 10/LOC. Smaller projects will average more as there's less involved with coordinating the groups, reviewing marketing materials, coordinating training with sales, etc, etc.

Chris Kessel
Thursday, February 26, 2004

> Thanks for your experience! This kind of data was really what I was looking for!

You're welcome. Actually, if you have a "team with many years of experience", it sounds to me like you could calculate this data yourselves based your own past performance.

One thing I don't quite 'get' about LOC is that, when I was making the detailed schedule estimate, I was saying "one day to code this piece of functionality ... two days to code that piece ..."; but I was doing that without quite saying "this piece of functionality will take 150 LOC, and I do 150 LOC / day, therefore one day for that piece". Perhaps I was estimating LOC without knowing it ... I suppose have a mental vision of how many 'pages' of code it will take to implement some functionality, rather than how many 'lines'.

A further point to note is that it's quite possibly worthwhile to get each developer to make their own estimates.

Christopher Wells
Thursday, February 26, 2004

> I think that's 3700 LOC / 62 days = 60 LOC / day.

Sorry: 4 months = 83 days, not 62 days. So, for me for that project, it was 45 LOC / day (not 60 LOC / day) including the pre-coding days; or 120 LOC / day if averaged only over the 1.5 months of not-much-except-coding days.

Also, if you read about "function points", they apply multiplication factors based on various things such as the type of software (e.g. a real-time protocol converter with an internal event-causes-state-transition machine is more complicated than a class for reading strings out of a 100 edit boxes on a screen).

Christopher Wells
Thursday, February 26, 2004

BTW, LOC is a perfectly fine way to estimate, if:

A) You measure it consistently across projects.
B) You are writing similar types of projects.

When those aren't true (particularly B), that's where function points come in. Function points are supposed to help measure differences in projects (complexity, size, market, whatnot).

Function points aren't easy though, usually takes training. For that matter, estimation isn't easy and so most people go on gut feel. But, even if it's a gut feel, it's good to at least back it up with a rationale.

"I did something like this at FooBar company. We had 5 people and it took 7 months. But we're only doing about half of that here, but ony with 3 people, so I'm going to guess around 3-4 months. I'll have to reestimate based on progress in a month or so though to give any kind of confidence."

Chris Kessel
Thursday, February 26, 2004

I'm sorry, I'm still stuck on "Hey, it only took you a week to derive the proof for 'corresponding angles of similar triangles are congruent' so how long will it take you to derive Fermat's Last Theorem? It appears to be much simpler..."

A different package
A different platform
A different working group
A decade of patches and changes

And you think your development team can average a line of code every three minutes for the months they'll be working?

If I were your boss and you said "150 LOC/day/developer" my first question would be "will you bet your job on that?"

You should approach it the same way - if one week goes by and the average is less than 120 LOC/day/dev (20% less), does he get to fire you immediately? If that makes you twitchy, I'd say you're being too optimistic.

Philo

Philo
Thursday, February 26, 2004

Given the nature and size of your app, you must have a pretty extensive test suite (unit and or acceptance tests) to go along with your code. if you assume that your code will be ported when your tests get to 100%, pick a handful of tests and the code they excerise. port and pass the tests in the new system. You can extrapolate code size and time taken based on current progress. this will if nothing else give you an empirical value instead of just sitting in your cube with project/excel inventing a number you hope your boss will accept to give you a greenlight.

mikester
Thursday, February 26, 2004