LargeRefactoringsDiscussion

From SPA Wiki

Ongoing discussion of Large Refactorings based on the results of the workshop LargeRefactorings at OT 2003.

--- I am going to write my PhD thesis on Large Refactorings, focussed on the teamwork issues in this area. Therefore I would be happy to discuss some of my ideas with you. 14. 4. 2003, MartinLippert --- Hi Martin,

It is very nice to see there are some (people at) universities taking the people dimension of software development seriously. Too often I have heard research groups say: 'we know nothing about psychology so we build only tools'. I think building tools or theory can not be done without understanding how software is actually developed - that means looking at it 'objectively' at least trying to reduce our prejudice to as how software 'should be developed'. I hope you have a PhD committee that understands this!

Letting go of my prejudice is to me one of the hardest things as a coach, especially with regard to work in a project like Large Refactorings. While I was at OT this year, the team I spend most of my time with was continuing its work - delivering stories, refactoring etc. All of the 'senior' people where in your workshop. The 'seniors' thought the 'juniors' are not (unlike 'us seniors') 'Explorers', we did not regularly find them reading books and doing experiments. I was pleasantly surprised when I came back after OT and they were spontaneously asking questions about some books I had dropped in the team (Smalltalk Best Practice Patterns and Test Driven Development). One of them had made a small architecture diagram (on an index card) to find gaps in our system and places where our interfaces could be more generic. They had also begun to think about where our system is using 'parsers' which to me is a big step, since the parser course they had had at school was not that good. And they had done some small experiments (spikes) to see where they could make parts of the system more 'parser like'.

So, what does this have to do with large refactorings? I realized that in order to let the team do (steps of) large refactorings on their own, I had to trust them and give them 'space' to do their own thing. Going away for a few days was at this point in time apparently much better than pair programming with them... Besides space they also needed knowledge, which they got (I guess) from reading and from us 'seniors' setting an example. I must admit I let in some sloppy coding of my own sometimes to get something done. This 'example' was copied just as my good 'parser' refactorings later on. Most important of all, this requires time and patience from the 'senior' people. Coming back to the team was for me a very pleasant revelation :-) So from now on I try to encourage the whole team (including myself...) to spike difficult refactorings besides working on new stories.

Only now I realized, that for the system to really grow further we might need a different architecture ;-) So I'm giving myself some time to do an 'architecture spike' outside the project. Build a quick run of a similar system, but starting from a slightly different set of forces than the other one - resulting in different patterns to be chosen. I guess this is an extreme version of ZoomOut (in the 'getting lost' section).

I'm not sure if this helps you, but your workshop helped me. Thanks! 14.4.2003 - WillemvandenEnde