Agile Otter Blog

We tackled some code for refactoring, and I found an unusual construct. To wit: public class Base: Many, Varied, Bases { private int x; // ... public class Derived: Base { public setX(int value) { x = value; } } // ... } So here we have the derived class nested in its base class. I am quite comfortable with nested anythings in python or a few other languages, so that's not a problem. I nest 'testable' classes in tests all the time so I can override or stub a few methods. In python it's a normal way of life to nest functions and classes. This one is odd because it is a production class, nested inside a production class, and deriving from its outer class. It makes me think of a pregnant female, having a child inside it whose dna derives from the mother. So what powers does this odd nesting convey? My first thought is that it is some kind of closure, but this turns out to be false. There is no real closure ...

I recently collected up some information from Jira and git about our software process. I am mulling over an idea, and a little feedback is welcome. To help understand the context, among our products we have one codebase that was originally written pre-agile in a non-TDDed manner but greatly improved during and after the company's agile transition. It is pretty good stuff, and constantly improving in quality and functionality, consistently delivering real value to customers. We're pretty of proud of it and its future. There is a great team working on it. Sometimes, though, we find the need for a large-scale refactoring somewhere in the code base, and we have the courage to tackle these. Basically the problem is that refactoring sounds bad to product managers. When it's done well, there is no visible difference in the code. When it isn't done perfectly, it injects defects. The obvious knee-jerk reaction is to resist any large-scale refactoring efforts. As an a...

I had some fun recently after agonizing over the problem of bug prevention.  I put out the observation that bugs have a tendency to cluster, and that the more often code is edited the greater the need for the code to be frightfully virtuous , clean , and thoroughly tested . The problem was with determining which code should be cleaned up in order to reduce the injection of bugs. I considered various metrics and measurements, including cyclomatic complexity, code duplication, and various design details, but ultimately dismissed them for fear that they would be unconvincing. I didn't want my audience to think the heat maps is just "coach Tim lecturing."  In keeping with our description of effective information radiators we needed the information to be simple and stark. Our SCM is based on git, and our tracking software is Jira. We have to include a recognizable, open, Jira ticket id in every code commit. Many of the tickets are enhancements, improvements, or investig...

I write an automated acceptance test (AT) and I find that I would like to perform certain actions against the business objects.  I create a method on the business objects and my test stays slim while my model builds up more functions. So, there is potentially code in the production system that is only used in the tests. The debate today is whether that is "unnecessary bulk that solves no business need" or is instead "first-class code." I am betting that the code you need in the AT is code you probably also needed in the UI and/or APIs to external clients. I am supposing that it is needed in the test because it is likely written into the UIs instead of the model and so the tests' logic is duplication. I also think that even a reasonably poorly-written test is written to support business rules.  Therefore, the tests express business logic so methods required by the tests are methods required by business.  While some worry that a method on a busin...

We had a nice talk today about the natural foot-dragging that is common among pair programmers when it comes time to switch partners. It's not really social, as in partners gravitating to each other as buddies. Instead it tends to be more work-related.  It does feel socially awkward to tell your partner you want to go work with someone else now. It sometimes does happen that partners who are gung-ho agilists will prefer working together. They prefer partners who allow them to do their work well and will improve them over those who create drag by arguing against testing or refactoring. People get comfortable in a particular task and want to see it through.  This is a good feature usually, and certainly is favorable for people who do individual, non-paired work. In an agile team, it's limiting. Someone needs to move on so that there are more eyes/hands/minds in the code. If there is no standup there is no pair switching.  If the team relies on assignment from a manage...

I've been developing new skills, and working with Jeff on the AgileInAFlash project . What's new? Our latest article for Pragmatic Programmers.

Vadim reminds me that I need to address root causes of Copy-Paste-Edit programming, rather than merely ranting about how bad a practice it is and how it ruins good code . Of course, he is right. That is part of being Vadim. I've previously ranted about the ill-effects of copy-paste-edit programming, but it would be unfair to say that there is never a need for it, or that people who did it were simply stupid and lazy.  The problem would not be so prevalent if it did not have some reasonable basis for practice. However well-intentioned and useful it is, its net effect on a code base is overwhelming negative. Here are a few root causes I recognize, and I'm open to hear more. Tedious construction semantics encourage copying. Many APIs are very thin access to bean-like objects, and yet using them correctly can be a trick. You have to know what to set, and in what order, and what to call next.  It is far easier to copy a correctly-set-up object use than to make one from sc...