Apparently, there was more to this and we had been talking past one another.
1) My interlocutor had developed a framework that he wanted to use, so
he already had an architectural goal - refactor until we can use his
framework.
2) My prime concern was that having a minority of the team refactoring
and a majority *defactoring* the code was going to lead us exactly
nowhere. But since this idea of teaching/mentoring/persuading the rest
of the team is "process improvement" and not "architecture" the person
with whom I have been arguing was not all that interested. I have no
objection to targeting this framework (although I am skeptical that we
can get to it in a reasonable period of time).
3) Other members of the team (not necessarily this guy) are not used
to refactoring at all, and would prefer to institute design reviews as
a way to get to quality. Many of them still see tests as a QA
responsibility that management is trying to foist off on development.
So we are going to start by reviewing the framework and discussing
what it will take to make the code base compatible with it. That may
be the time to press for retrofitting tests and refactoring. The issue
of bringing the rest of the organization along is something I may have
to take up with management. I think our group's performance gives us
the credibility to make the case that it is a good idea.
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/
