How much is too much?

[ziloo]

Some times ago, I read in a book about "Object Oriented Programming"
that a professional programmer can write as much as 20,000 lines of code
(or was it 200,000 ? I can't recall!) :computer:. That is a lot of code to
put together and debug provided that it is not made of repetitive modules.

In your opinion, what is the largest program that one single individual
can write, debug and fully understand :confused1:?

[JDT]

Some times ago, I read in a book about "Object Oriented Programming"
that a professional programmer can write as much as 20,000 lines of code
(or was it 200,000 ? I can't recall!) :computer:. That is a lot of code to
put together and debug provided that it is not made of repetitive modules.

In your opinion, what is the largest program that one single individual
can write, debug and fully understand :confused1:?

Who knows, but thats what comment lines are for! :cool:

[alexkerhead]

In your opinion, what is the largest program that one single individual
can write, debug and fully understand :confused1:?

A limited semi-gui operating system.

[SwedaGuy]

Well, right now I'm working on reverse engineering a program that's around 14,000 lines of uncommented assembler. Now that I've worked through and commented vast sections, it's around 19,500 lines. It's a tedious task, and I imagine building the program from scratch would be significantly easier.

I dont' think that the number of lines of code are really the biggest factor, but rather the scope of the data to be processed. If you're planning one program that is supposed to be the do-all, end-all, with every function imaginable, that program is going to be more difficult to conceive, code and debug than a program with a clear, fixed, discrete task.

My partner, a C programmer, can turn out 20,000 to 30,000 lines of production code in a month. Obviously, he doesn't do this every month, but when we have an important project on tap, he comes through.

I guess I don't really think that any amount is too much if you build up to it, and have a concise plan. Starting a big project without the appropriate specs on paper is just asking for trouble. Those specs may change as new needs are identified or as procedural errors crop up, but at least the specs can be pointed to as the original plan.

This also gives you a scope to work within. As anyone who has ever done contract programming knows, the customer will change their mind like they change underwear...so make sure you have on paper exactly what the program should encompass and make sure they know anything above and beyond will cost more. Otherwise, every time you think your finished, they will request another feature...

So, type till your fingers are numb, as long as you think you will know the end when you find it.