Fog Creek Software
Discussion Board




Understaffed

Long lives team work! My colleague and I: we are responsible for a 70,000 loc (C++/Java) project - maintaining, fixing bugs, adding new features, documenting, grooming the daily build,  ...

The longer I think about it, the more I get the feeling that this is too much code for such a small two-member team.

Am I correct or wrong (or just overworked a little)? I'd like to hear your experiences about how many code lines one brain can handle at maximum - about how many lines *you* are responsible for?

What is a reasonable "lines of codes per head" ratio?

- Roland
Wednesday, September 17, 2003

We're doing a similar sized project, cross-platform, C/C++ and have 3 people. However, we did one slightly smaller last year with 2 people and I definitely felt overworked.

jedidjab79
Wednesday, September 17, 2003

What's a good program free program for counting lines of source on Windows?  I tried google one, but I've had no luck so far.

As the sole programmer in my organization I'm responsible for 2,163 source files totalling 8.7MB.  It *feels* like alot of code but I'd really like to know the LOC count for comparison with you guys.

Almost Anonymous
Wednesday, September 17, 2003

Well, speaking as someone who's maintaining 70k lines of code *and* sysadmining three networks *and* DBA for two SQL Server databases *and* providing user support *and* developing a new project... [grin]

However, I suspect my ability to do this is rooted in the technology that went into the platforms. It's all Win2k & SQL Server, and the code is all C#. So I find admin, maintenance, debugging, and developing to be a breeze. Not easy, mind you, and I still have to deal with the occasional heisenbug that will eat a day or two, but in general I think the tools are what make this possible.

Philo

Philo
Wednesday, September 17, 2003

Hey Philo,

How much do you get paid for all that?  I might have to ask for a raise...

Almost Anonymous
Wednesday, September 17, 2003

Looking at it from LOC will not tell you much.

I'm one guy and wrote a large commercial application with 10x the number of lines you produced. LOC thinking would say that my project was more difficult. But doubt it. Being that it was written in a 4GL and 90% of the code is UI related, the complexity of the application was quite minimal.

A lot of factors go into your code size such as the language your write in, the platform you develop for, and the application's functionality.

So a math centric app in a 3GL might take less lines of code than an database app a 4GL, but that doesn't mean that the database application is more complex (I would suggest quite the opposite).

While I'm churning out code at light-speed, you might very well have been working just as hard - if not harder - to develop 3 lines of complex calculations.

Marc
Wednesday, September 17, 2003

Almost,

My guess is not enough. :)

Marc
Wednesday, September 17, 2003

Almost overworked: I use the cygwin tools [ http://www.cygwin.com/ ] ...

After doing so, a "grep -r ; *.cpp | wc" gives me a good approximation of lines-of-code.

Alyosha`
Wednesday, September 17, 2003

Marc, understood about the 4GL, and even moreso if you're using CASE tools. But isn't it a tradeoff? For example, on an ASP.Net page, yes I may have 10-20 lines of generated control constructors, but on the other hand, ASP.Net is doing a lot of stuff for me behind the scenes (viewstate, postback, etc), so an ASP.Net page is actually *shorter* than an ASP page that's doing the same thing (and the code that's there is closer to pure business logic).

OTOH, comparing C# to C++, isn't a lot of C++ related to memory handling (which is harder to manage and debug than simple business logic)? So C++ code to do the same as C# would be longer *and* harder to work with?

I look at it this way - first, be wary of comparing apples to oranges, and secondly, kloc can't be used for fine measurements (what have you done today), but are a good approximator for gross measurements (how big is your project?).

Philo

Philo
Wednesday, September 17, 2003

To me it would depend completely on the type of code.  If it's homogeneous it would be easier to work on than if it does 50 different things.  It you and your coworkers wrote most of it it would be easier than if you have to code read it to figure it out.  If it's well designed and commented it will be a lot easier than a big mash of stuff.  It it's simple it would be easier too; mind bending implementations of complex math could be a very small number of lines but very hard to work on. 

D
Wednesday, September 17, 2003

LOC Calculator:

http://www.analogx.com/contents/download/program/kloc.htm

Jack Thybolt
Wednesday, September 17, 2003

The first question to always ask, of course, is "Are there too many lines of code?"  If a different design can accomplish the same thing with fewer lines of code, you should do it.  Might take a while to get there, but with good refactoring practices, eventually you will.

Over the past year, we have drastically REDUCED the number of lines of code in our application, while adding lots of functionality.  Performance improved, maintainability is way up, and it's much easier to add new features.

Jim Rankin
Wednesday, September 17, 2003

I got AnalogX KLOC counter and ran it on my core codebase:

125,870 LOC

AnalogX counts comments as well as code which no doubt inflates the number considerably.  Of course, if one looks hard enough, one will in fact find the kitchen sink in that code.

Almost Anonymous
Wednesday, September 17, 2003

I've gotten to the point now were I cannot refactor the current application get it to where I want it to go.

The application scope is so far beyond the original design that it's now the major handicap.  I have to rip out the guts and go with a complete redesign to move any further on the project.  I have the design all worked out but the time and money isn't there to work on it.

I believe the redesign would reduce my code-count by half while retaining all the existing functionality.  It's a perfectly good example of why KLOCs are not a good measure of performance.

Almost Anonymous
Wednesday, September 17, 2003

"I've gotten to the point now were I cannot refactor the current application get it to where I want it to go."

Don't lose hope.  Pick one thing about whatever part of the app you're working on now to tackle.  It will probably make whatever you're doing go faster, anyway.

Don't have time to look it up, but one of the XP type books talks about "code smells", things that tell you there's a problem, then suggests ways to tackle them.

Jim Rankin
Wednesday, September 17, 2003

The LOC is irrelevant on its own. You need to measure the complexity of the code not just "how many lines are there".

Dino
Wednesday, September 17, 2003

"Don't lose hope.  Pick one thing about whatever part of the app you're working on now to tackle.  It will probably make whatever you're doing go faster, anyway."

Everything is so terribly interrelated!

I have about 4 key areas that need improvement (some things don't need to be touched; they all got refactored earlier this year).  If I do all 4 areas at once then it's less work than trying to change one and make it work the design of the other parts.  Only when all 4 areas are redesigned together does it really work.

Almost Anonymous
Wednesday, September 17, 2003

LOC doesn't tell you how much you needed to write to get where you are. It tells tells you how much you have to read and understand before you can get somewhere else.

Devil's Advocate
Wednesday, September 17, 2003

Another LOC calculator:

http://www.dwheeler.com/sloccount/

Skips comments, works on many languages.

Chris Winters
Thursday, September 18, 2003

How many lines of code (LOC) are here ?

C#
Private int MyBrilliantFunction()
{
      if{MyIQ > 160}
      {
              The most brilliant line of code - ever;
              Return theBrilliantResult;
        }
}

Or

VB.NET
Private Function MyBrilliantFunction() As Integer

    If MyIQ <= 110 Then
        Future FogBugz bug #13278
        Return BugID
    End If

End Function

In both cases, does the LOC take into account the blank spaces ?  The lines with only brackets in C# ?  What about the 'End Function' line in VB ?

Wouldn't it make more sense to qualify the LOC with something along the lines of - app has 1073 routines with 4012 LOC (omitting the function names, blank spaces, bracket lines and 'end' statements ?

Kentasy
Thursday, September 18, 2003

That K-LOC tool is a joke. I told it to do *.cs and it came back saying that there was 11033 files, comprising 116MB. Funny, when I do a dir /s *.cs, I get 3035 files in 6.5MB. Even if I give it the benefit of the doubt and do a dir /s for EVERYTHING, it's still only 7998 files making 109MB.

How can you trust a COUNTING tool that can't even count files and file sizes?

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, September 18, 2003

"Am I correct or wrong (or just overworked a little)? I'd like to hear your experiences about how many code lines one brain can handle at maximum - about how many lines *you* are responsible for?"

Lingo has reached approx 200,000 LOC, for which I am solely responsible, along with my cats http://www.lingolanguage.com/news.html . Lingo consists of Delphi Pascal, C, Lingo source, Intel assembler and EBNF.

I've included comments in the total and I view them as equally important. Maintenance would not be possible without them. Also the hardest bugs which take a week to fix usually require 3 extra lines of code and a 100 line dissertation on exactly why the Windows API works that way.

Bill Rayer
Thursday, September 18, 2003

*  Recent Topics

*  Fog Creek Home