Fog Creek Software
Discussion Board

Estimating headcounts

Are there benchmarks available to estimate the development team size for the maintenance of a system (say ASP and VB)? I also see some discussions on lines of code in here, so are there any benchmarks for lines of code productivity?

Kenneth Hall
Sunday, March 24, 2002

That's stupid, IMHO.  It depends on a million other things, specific to nature the app itself, and the business. 

Does it require frequent updates, or has it been unchanged for years? 

Also a giant program, written well, may require less maintenance than a small app that was written like crap.

It also depends on the skill level of the people maintaining the app.

This is not something that can be plugged into a spreadsheet.  Use your head, examine the situation, track it over some time, and make an educated guess...

Sunday, March 24, 2002

Ammm.. actually the situation is like this. We have a team has been working 12 to 18 hours every day, weekends and all, (interesting to see post on long hours and age above this one), for a couple of years to deliver our product. We now has a successful product, with a reasonable size customer base. There is an opportunity to expand our customer base by about 200 fold with a channel partner, and we are working on budgets and resource requirements to move forward. We have come up with numbers based on our history, but it seems prudent to check out what else is available, if anything. The notion is that we may not want to maintain the long hours, so... how many heads should we have... is the question.

By the way, relating to the post regarding hiring people over 35. There are five of us on this team, all are over 35, all married, and three of us are close to 50. All of us have been working the long hours. Three of us have kids.

Kenneth Hall
Sunday, March 24, 2002

For whatever its worth. Code base is about 70,000 lines, ASP, VB, Javascript, and MS SQL store procedures. Fair amount in SQL SPs. New modules planned will increase code base by about 20k lines annually for the next two three years.

Kenneth Hall
Monday, March 25, 2002

It's very difficult to estimate programmer headcount if you don't know the heads you're counting. The difference between the productivity of a good and a mediocre programmer can be tenfold.

LOC is not always a useful quantification of productivity. This short article,,12065_988641,00.html provides some good reasons why.

Increasing the headcount does not result in a linear increase in overall productivity. The more people involved, the more time will be spent communicating. So you may end up having to hire more than 10 average VB programmers to make up for one really good one.

If you all have been working 12-18 hours daily and have families, you can't be happy, and there must be something wrong with your process. Sounds to me like you didn't have specs or schedules, and you were "almost done" for just about the entire duration of the project.

If that is correct, I suggest the first things you do are:

  1 - write specs for all new subsystems
  2 - schedule 8-hour working days

What you'll find is that you'll spend less time writing and debugging the wrong thing, you'll know when you're done, and you'll know if you need to add more manpower. How much depends on who you end up hiring. There's just no way to tell how long it will take until you've got the guy who's doing to do it.

Monday, March 25, 2002

Read "Debugging the Development Process" by Steve Maguire.

Frederik Slijkerman
Monday, March 25, 2002

Years of those hours???  Wow, I feel terrible for both you & your family.  Really.  You have a real case to say, "look, I'm working 40 hours for a WHILE, or FUCK YOU"  You know the code, and now YOU have the bargaining power, as it would take a year for someone to know what you know. 

Ignoring one's family is no way to live.  Your wife must raise them family on her own, and you hav e become nothing more than a paycheck.  This is what I'm trying to avoid in my own life.

Monday, March 25, 2002

I've made a few attempts at posting this same reply. Hopefully, only one will get posted.

"Practical Software Maintenance" by Thomas M. Pigoski contains a chapter on maintenance metrics. He addresses mostly large systems written in 3GL. However, research quoted by McConnell in "Rapid Development" suggests that developers code at about the same rate in any language (as measured in KLOC/month).  So one would expect maintenance rates to be in the same ball park across languages.

25-75 KLOC per programmer is the rough range, if memory serves. Where you are in that range depends on a variety of factors. If you try to maintain more than 75KLOC per developer, your system will degrade at a noticeable rate.

Wednesday, March 27, 2002

Thanks for the info from those of you with useful input. Every bit help.

Everybody else:

I am doing what I enjoy most, writting code and creating a product. We have a good team and we enjoy working with each other.

My familiy is excited at what is happenning, and several years of hard work, compared to what a lot of people in this world have to do, is nothing. We are lucky to have this opportunity.

I forgot to tell you, we did this without VC money, so us founders own most of the business.

We are looking at globs of money, so this exercise is to figure out how much of the glob to allocate so that we can add enough resources to slow down our workload and meet our committments.

So eat your heart out, I am signing off.

Kenneth Hall
Thursday, March 28, 2002

*  Recent Topics

*  Fog Creek Home