Beautiful Teams

Learning

Paul and Alex were fairly new employees at BBS, with one or two years of experience, if I remember correctly. I got to spend the most time with them. The senior people kept getting pulled into meetings, so the three of us had plenty of time to work. Being the seasoned journeyman, it was like having two apprentices. We worked day to day, incrementally developing. Like I mentioned earlier, I was at BBS only every other week, on average. So on Fridays, we would plan the next week's work.

Paul and Alex were great. They always got everything done that we planned on doing. The code was well tested and it delivered the desired functionality. As their mentor, I reviewed their work when I returned the following Monday. They always got the code to work, but they usually put some code in the wrong place. What I was detecting was something that Martin Fowler calls "feature envy" [4].

Code problems now have names! Fowler and Beck did a fine job naming and describing a small catalog of "code smells." Feature envy was where one class was doing the job of another class. There were others: long method, large class, long parameter list, lazy class, and shotgun surgery, to name a few. Just having the name for some undesirable code quality helped us detect problems early and keep the code clean.

So, Alex and Paul would leave these small code problems around, but it was no big deal; Monday became refactoring day. We had the tests, so it was easy and low-risk to move the envious code to its proper ...