Programmers are expensive. The results of their work must be captured and used for the benefit of their organization. The trouble is, the traditional packer way to count results is to count what they can be seen producing. The results of a programming team studying a problem, coming to an understanding, and testing that understanding down to the ultimate rigor of executable code are not the KLOCS of code they typed in when they were learning. They are the final understanding that they came to when they had finished.
The reason why it is important to identify a value that way around is that sometimes, the understanding shows a much easier way of doing things than the design the team started with. A classic mapper/packer battleground in programming consists of the mappers seeing that with what they know now, a reimplementation could be done in a fraction of the time, and would not suffer from maintenance issues that they see looming in the existing code. The Packers see the Mappers insanely trying to destroy all their work bias (if there weren't backups) and repeat the last few months, which have been terrible because they obviously didn't know what they were doing anyway (they kept changing things). The packers set out on one of their crusades to stop the mappers, and the organization has to abandon its understanding, which cannot be used in the context of the existing source code.
The intelligent organization wants the most understanding and the least source code it can achieve. The organization stuck in inappropriate physical mass production models doesn't count understanding and counts its worth by its wealth of source code, piled higher and deeper.
Copyright (c) Alan G Carter and Colston Sanger 1997
Top comments (1)
KLOCS are thousands of lines of code