Agile Otter Blog

Balance these facts: Refactoring is a good thing, but is also perturbation. Gratuitous perturbation is a bad thing. Refactoring is good because confusing, stupid, repetitive, complicated code is the devil. We can't even pretend it is not the devil, because we catch bad code sneaking away with a slice of our souls from time to time. Bad code is bad. Refactoring makes bad code better. Some perturbation is a very good thing. Gratuitous perturbation of the code base is a bad thing. If I make a million changes to a million places, then diffing (and therefore merging) are going to be a slice of hell. This is a different devil, but still a devil. The problem with perturbation is that it makes it hard to maintain branches. Branched development is a good thing sometimes, providing some isolation for a very short period of time, and some ability to compose and recompose a release. Branching becomes odious, however, when the code in a branch differs greatly from the code in a shared c...

The svn fail I see most is like this: # some line ==== >>>>> other Now, how is it a conflict that I added a line of code and trunk didn't? I will freely admit that the diffing stuff is very smart and not very easy. I want to cut a lot of slack, and I'm happy that this is easy to resolve, but I really have to wonder how that is not an update rather than a conflict.

Please help me read your code. I know you don't owe me anything, and you can run your code even if it doesn't pass the Agile Otter Sniff Test. I appreciate all of that. But I think that you and I can both do a better job if we're just up-front about things. I find little speed bumps in most code, and it breaks my fragile concentration . Maybe writing on index cards has made me parsimonious, but now I believe that less is more. I can read your code better if there is less of it, and it's more obvious. A function should not have many effects on the code. Don't code things into the same function just because they happen at nearly the same time. You do not have to shoehorn your new code into an existing class. Clear a space for it. Extract classes when it makes sense to do so. Use less horizontal space. Long lines and lines with long blank leaders cause my eyes to cross and make me scroll my windows to see if there's something I want to read. This is more ...

I was in denial for quite along time. I thought that there were really no tasks that couldn't be broken down and implemented in phases. I'm in a change now that is trying my ideals. Of course, this is a cross-cutting concern that deals with a big "ility." In particular it deals with scalability but I don't want to provide a bunch of detail that will distract us from the point. The code is legacy in both the MFeathers meaning "without unit tests" an in the sense of "handed down from one generation to another, unsuspecting one." The new generation has done some excellent work getting huge tracts of land cleared and fenced with TDD and AT and what-have-you. Really, quite the transformation. The original designers had a philosophy and working style that did not survive the transformation (we think for the better) so there are architectural/design decisions being unmade on a regular basis. In particular, there is this giant jellyfish of a des...

Patch files are no fun. Look at this little bit from the SVN Red Bean Book In this particular example, there really isn't much difference. But svn merge has special abilities that surpass the patch program. The file format used by patch is quite limited; it's able to tweak file contents only. There's no way to represent changes to trees, such as the addition, removal, or renaming of files and directories. Nor can the patch program notice changes to properties. If Sally's change had, say, added a new directory, the output of svn diff wouldn't have mentioned it at all. svn diff outputs only the limited patch format, so there are some ideas it simply can't express. I only mention this because I've had a recent hiney bite in the combination of patch and svn.

Sometimes you read an article and realize, "Hey! I've been there!". I was following some tweets the other day and was directed to an article on The Blame Game , which explains how things work in a culture of blame. I've definitely seen this at work at least two or three times in my 30 years of programming. It's a tough situation. Here is a diagram about how the system remains and escalates over time: I did find that promoting transparency in a culture of blame is not so much a way of creating change as a way of attracting blame. It was a difficult lesson.

I saw a recent article describing one team's use of a Story board . I mention it here, because it's the same way I've set up the last two. Love it or hate it, it's also what I've been doing.

I just watched an Ira Glass video about taste and sticking with your work, and practicing. Of course, any attempt to compare myself to Glass will end in disappointment for me. I work with a great programmer. He holds more of the system in his head than I do, and is more comfy with the environment. We were sketching different ways to go forward, and before lunch he showed me a direction I really liked. It harmonized ideas from various conversations, and is well-timed. I did feel something was a little off, but I was confused about what it was. I blame it on mondays, especially since I was busy with many things this weekend (departing friends, graduation open house, etc). I got lost between C# syntax and C or Python at one time, and only frustrated myself (and surely my gracious partner too). Finally I realized that I was being confused over an asymmetry I had noticed earlier. I couldn't even phrase the concern (well, without being intense) other than it was asymmetrical. That sound...