How much code can a programmer be intimately familar with?

Question

Are there any statistics for this? I realize it must vary from person to person, but it seems like there should be a general average.

The reason I ask is that the company I contract for has multiple software products, totaling ~75,000 lines of code - and they seemed disappointed and shocked when they ask me a question about a specific portion that I don't immediately know the answer to (I am the only programmer they have, and did not author the majority of the systems) They think I should just know it all from memory. So I wanted something like a statistic to show them that an average programmer couldn't possibly have all that in his head at one time. Or should I?

Answer 1

You should remember where to find the needed stuff not remember it itself.

You should also be familiar with code structure and architecture enough to make an educated guess where a problem might originate and where you could possibly find the stuff you know exist but not sure where exactly.

You brain works like cache. The stuff you used recently is kept there, more older entries are erased. But there will never be enough memory to remember the code all at once. Because then you will want to remember all API functions, then all specs, then something else. This all is not feasible.

And being surprised with you that you don't remember all the code is probably one more instance of those perversed notions of how programmers do things. Ignore them.

Answer 2

Even if you have written all that code you might forget portions of it. But you'll be able to recall it once you review it.

I think its natural for a programmer to forget some portions of his/her code after a long time.

Answer 3

It depends not only on your memorization skills, but also a lot on the code. Obviously, clean, idiomatic code is much easier to memorize than a badly written inconsistent mess. Probably because clean code can be broken down into much larger "abstract tokens".

Answer 4

Ask them how they want you to spend your time: surveying vast amounts of code you didn't write and perhaps writing up internal documentation, or whatever currently keeps you occupied It's not a facetious question. If they want quicker response to new issues, they need to invest in research.

I don't think there's a meaningful answer to this measured in LOC. As a manager, what I want to know is that someone in your situation can answer a question in a reasonable amount of time -- and unless I know you're in the middle of something, I wouldn't expect that 'reasonable amount of time' to be 'instantaneously'.

Answer 5

You should be able to understand all the components within the system and how they interact so that when there is a problem you can isolate one or two likely components and drill down.

I find it helpful to draw a few diagrams and keep them handy so I can use them to communicate with my boss\customer as well as jog my memory.

Answer 6

Indeed interesting question but I am in doubt if there is adequate answer at all. Here are only obvious factors I see right from the start:

• Overall design quality. Even if you are new in well designed code you can very quickly identify where you should look to get answers.
• Project documentation quality. For poor documented projects even developers that are in project from the start can't say anything about some parts.
• Implementation quality. OK. You have good general architecture, good documentation for interfaces but even one really bad programmer could break all of this. This is because many companies are very strict about code reviews and I think it is the only one technique to prevent such situation.
• Programmer experience. As you move ahead you see number of 'already known' code "bricks" in software new to you and experience is great help in this so contractors are often very experienced specialists familiar with various approaches and this gives average contractor ability to move much faster then full time programmer which is brilliant but worked 10 years in only 1 project context.
• General person smartness. My opinion this is really not so important as most of others factors but it is really important.

... but the common problem is often companies hire contractors for some existing software improvement and they simply think this is only about to hang picture on the wall. You should perform some negotiation to force them to understand part of work is to understand what really should be done to meet their requirements at all. And such "learning" requires resources and is part of work itself. But I think it is slightly off-topic for StackOverflow (despite I voted up ;) ). Is it more for Startups discussion?