--- "Kenneth Tyler" <[EMAIL PROTECTED]> wrote:
> [...] The argument [...] is that the most valuable part
> of a body of code is the contextual knowledge held by
> its creators. [...]
On the other hand, some people might think that the most important
and valuable property of a program is that it works.
(IE: that is works correctly -- that it produces the desired result)
_ _ _
Let's Suppose... ;->
Suppose you had a program that was perfect (or close enough), and
somehow knew that you would never need to change it again. How
valuable would "the knowledge held by its original creators" be?
Say you fired the creators, and later found that you needed to change
the program. So you hire some new people, and they change the
program. Now: How valuable has "the knowledge held by its original
creators" proven to be?
You have *LOTS* of changes for the program. And maybe the new
developers find that some significant amount of refactoring is
needed. Now you have a program that is different from the original
program in a number of significant ways. So, at this point, how
valuable is "the knowledge held by its original creators" to you?
Some months later, your business changes again, and you need to
change the program again. At this point, how valuable is "the
knowledge held by its original creators" to you?
Is this an unreasonable scenario? Is what I just described so unlike
anything any of us have experienced in the real world, so as to be
completely unbelievable? ;->
_ _ _
On a number of different projects, I have encountered people with
belief systems that seemed to hold that the original "design" -- all
the way to class names, method names, and variable names -- are
sacred, and must never be changed. That the "original developer" had
some "perfect insight" that no future developer could ever hope to
achieve. And so no one dare change anything done by the magical and
perfect "original developer."
Somehow, this strikes me as voodoo. I think the original developer
may have been drunk, on drugs, and/or largely clueless about a great
many things. Everyone I know, including myself, knows less about the
business at the start of a project than at the end. I just can't
hold that "the original developers" always hold some kind of superior
knowledge that can never be improved upon over time.
As time progresses, we will, generally speaking, know more than we
knew before.
(The only good exception that comes to mind is stuff we forget.)
I think I can understand where some people may be coming from, when
they hold this "original developer" belief: When working on bad
legacy nearly unmaintainable code, it can certainly seem like you'll
never be able to figure out what the business requirements are: Just
about every time you think you fully understand, and make some
reasonable change, some unknown business requirement regression comes
and slaps you back. (This is a case, of course of the business
requirements having no automated regression tests.)
However, this is bad code. It's not a great insight into the
fundamental nature of software development.
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
