2 spelling, mistaken word choice, reworded one hard to parse sentence
source | link

There are many good points in the other questionsanswers, but I think they miss or don't emphasize an important conceptual mistake you make:

You are comparing the effort to understand the complete program.

This is not a realistic task with most programs. Even simple programs consist of so much code that it is simply impossible to manage all of it in the head at any given time. Your only chance is to find the part of a program that is relevant to the task at hand (fixing a bug, implementing a new feature) and work with that.

If your program consists of huge functions/methods/classes this is almost impossible. You'll have to understand hundreds of lines of code just to decide if this chunk of code is relevant to your problem. With the estimates you gave it becomes easy to spend a weakweek just to find the piece of code you need to work on.

Compare that to a code base with small function/methods/classes named and organized into packages/namespaces that makes it obvious where to find/put a given piece of logic. When done right in many cases you can jump right to the correct place to solve your problem, or at least to a place from where firing up your debugger will bring you to the right spot in a couple of hops.

I have worked in both kinds of systems. The difference can easily be two orders of magnitude in performance for comparable tasks and comparable system size.

The effect ofthis has on other activities follow from that:

  • testing becomes much easier with smaller units
  • less merge conflicts because chances for two developers to work on the same piece of code are smaller.
  • less duplication because it is easier to reuse pieces (and to find the pieces in the first place).

There are many good points in the other questions, but I think they miss or don't emphasize an important conceptual mistake you make:

You are comparing the effort to understand the complete program.

This is not a realistic task with most programs. Even simple programs consist of so much code that it is simply impossible to manage all of it in the head at any given time. Your only chance is to find the part of a program that is relevant to the task at hand (fixing a bug, implementing a new feature) and work with that.

If your program consists of huge functions/methods/classes this is almost impossible. You'll have to understand hundreds of lines of code just to decide if this chunk of code is relevant to your problem. With the estimates you gave it becomes easy to spend a weak just to find the piece of code you need to work on.

Compare that to a code base with small function/methods/classes named and organized into packages/namespaces that makes it obvious where to find/put a given piece of logic. When done right in many cases you can jump right to the correct place to solve your problem, or at least to place from where firing up your debugger will bring you to the right spot in a couple of hops.

I have worked in both kinds of systems. The difference can easily be two orders of magnitude in performance for comparable tasks and comparable system size.

The effect of other activities follow from that:

  • testing becomes much easier with smaller units
  • less merge conflicts because chances for two developers to work on the same piece of code are smaller.
  • less duplication because it is easier to reuse pieces (and to find the pieces in the first place).

There are many good points in the other answers, but I think they miss or don't emphasize an important conceptual mistake you make:

You are comparing the effort to understand the complete program.

This is not a realistic task with most programs. Even simple programs consist of so much code that it is simply impossible to manage all of it in the head at any given time. Your only chance is to find the part of a program that is relevant to the task at hand (fixing a bug, implementing a new feature) and work with that.

If your program consists of huge functions/methods/classes this is almost impossible. You'll have to understand hundreds of lines of code just to decide if this chunk of code is relevant to your problem. With the estimates you gave it becomes easy to spend a week just to find the piece of code you need to work on.

Compare that to a code base with small function/methods/classes named and organized into packages/namespaces that makes it obvious where to find/put a given piece of logic. When done right in many cases you can jump right to the correct place to solve your problem, or at least to a place from where firing up your debugger will bring you to the right spot in a couple of hops.

I have worked in both kinds of systems. The difference can easily be two orders of magnitude in performance for comparable tasks and comparable system size.

The effect this has on other activities:

  • testing becomes much easier with smaller units
  • less merge conflicts because chances for two developers to work on the same piece of code are smaller.
  • less duplication because it is easier to reuse pieces (and to find the pieces in the first place).
1
source | link

There are many good points in the other questions, but I think they miss or don't emphasize an important conceptual mistake you make:

You are comparing the effort to understand the complete program.

This is not a realistic task with most programs. Even simple programs consist of so much code that it is simply impossible to manage all of it in the head at any given time. Your only chance is to find the part of a program that is relevant to the task at hand (fixing a bug, implementing a new feature) and work with that.

If your program consists of huge functions/methods/classes this is almost impossible. You'll have to understand hundreds of lines of code just to decide if this chunk of code is relevant to your problem. With the estimates you gave it becomes easy to spend a weak just to find the piece of code you need to work on.

Compare that to a code base with small function/methods/classes named and organized into packages/namespaces that makes it obvious where to find/put a given piece of logic. When done right in many cases you can jump right to the correct place to solve your problem, or at least to place from where firing up your debugger will bring you to the right spot in a couple of hops.

I have worked in both kinds of systems. The difference can easily be two orders of magnitude in performance for comparable tasks and comparable system size.

The effect of other activities follow from that:

  • testing becomes much easier with smaller units
  • less merge conflicts because chances for two developers to work on the same piece of code are smaller.
  • less duplication because it is easier to reuse pieces (and to find the pieces in the first place).