Jeff Grigg wrote: > 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?
Of course. Naur's article discusses what is important for actually pursuing the development of a program. > 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? Very, as anyone who has tried this will know. BTW, Naur's point is not about "knowledge". Knowledge can usually be put into documents. He argues that developers build a /theory/ of how the program works, and that this is something that can only live in people's heads. He further argues that when people who do not have this theory modify the program, the result has less integrity. > 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? I think that a certain amount of refactoring, done by new developers, is a matter of "taking ownership" of the program. They then build their own theory about it. Until they've completely refactored every line of existing code, it is likely that the program will exhibit a bit of schizophrenia. > 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? ;-> You seem to be saying that it is not impossible for new developers to modify a program. You have done little to convince me that they can do so more effectively than the original programmers would have. Also, to me, Naur's idea suggests that for a new team to modify a program, refactoring the legacy code may not be as efficient as adding, wrapping and replacing. To Alistair Cockburn, it also suggests that for any team, sitting together and having a system metaphor could be more effective than throwing documents over walls. All in all, I wouldn't dismiss the article. It has some interesting consequences. Regards, Dominic Williams http://dominicwilliams.net ---- 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/
