On 12/31/12 2:58 PM, Paul D. Fernhout wrote:
Unless you know what to look for (and even sometimes if you do), it is
hard to tell whether a programmer spending a month or two refactoring
or writing tests is making the system better, or making the system
worse, or maybe just is not doing much at all.
Sometimes I see codes that have data structure traversal procedures cut
and pasted into several modules without any apparent effort to abstract
them into a map/operation high order form or a parameterized macro
expansion.
I think for reasons like:
1. The logic to do the traversal is intermingled with the operation to
be done at each site. The programmer knows the outcome of the whole
operation from the context they cribbed the code, but they don't want to
think about the details. And why should they `reduce their
productivity' (e.g. lines of code per unit time) by refactoring the
cribbed code if the original author couldn't be bothered?
2. The programmer has a belief or preference that the code is easier to
work with if it isn't abstracted.
It's all right in front of them in the context they want it. Perhaps
they are copying the code from foreign modules they don't maintain and
don't want to. They don't think in terms of global redundancy and the
cost for the project but just their personal ease of maintenance after
they assimilate the code. If they have to study any indirect
mechanisms, they become agitated or lose their momentum.
3. The programmer thinks they are smarter than the compiler and that the
code will be faster if they inline everything and avoid function calls.
In any case, a manager confronted with this situation can choose to
reward individuals who slow this type of proliferation. An objective
justification being an increase in the percentage of lines touched by
coverage analysis profiles across test suites, unit tests, etc.
Marcus
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
