Development cost of NOT using range names

[ChrisGreaves]

I've been searching (unsuccessfully) for a paper, any paper, that attempts to document the cost of NOT using range names during spreadsheet development.
I was hoping for something that pointed out that we humans have not evolved to deal well with "A34" and "GH178", but that we are well-equipped to deal with "TotalCosts" and "NetRebates".

My first guess would be that in terms of raw development and comprehension of formulae, both for the excel coder and for the sponsoring managers, NOT using range names could easily double development time.

Comments?
(I am, of course, talking about serious applications, not the throw-away calculation of how many days until Christmas)

[HansV]

I very much doubt that you will find such a paper.

[Jan Karel Pieterse]

Whether or not using range names is good spreadsheet development practise has been a discussion point for decades. You'll probably be able to find plenty of such discussions, maybe they help?

[ChrisGreaves]

I very much doubt that you will find such a paper.

me too (glum)

[ChrisGreaves]

Whether or not using range names is good spreadsheet development practise has been a discussion point for decades. You'll probably be able to find plenty of such discussions, maybe they help?

Thanks for the comment Jan Karel.
I doubt that discussion will help me. My mind is pretty well made up that our brains are not equipped to assign significance to "A34" or "GH178". If you think about it, a spreadsheet with cell references forces the brain to translate to "TotalCosts" and "NetRebates" each time we see the formula, so using "TotalCosts" and "NetRebates" from the get-go has to be more time-efficient.
Throw in the various tools and utilities for automatic naming and use and it just has to be a winner.

Machine-language was superseded by assembly-languages for just that reason; hence the move from IBM 1401 machine language to SPS-1, SPS-2 and Autocoder (which is where I came in ...), and from that level to FORTRAN, COBOL and the like, right up to drag-and-drop of controls onto GUI forms.

Nonetheless if you have any references to threads/arguments I'd be delighted to read them.

I'm guessing that most objections will be from the coders who see it as "extra work", rather than the project managers who see symbolic names as "a reduction in maintenance and comprehension costs".

[Jan Karel Pieterse]

You could also argue, that using names ADDS complexity to your formula's, as it will take extra steps to find out exactly which cell(s) a name point to.

As much as I am an advocate of using range names, there are more drawbacks.

People tend to drag sheets around and that action drags range names with them (potentially creating either local range names duplicating global ones, or creating external links to the original file, or adding new range names to the target file).
The list of range names is not easy to look at, mistakes are hard to spot.
IN general: Range names are a good idea, but they take meticulous maintenance.