Agile Otter Blog

I have had at least two people tell me that windows works very smoothly for them, and that it handles whatever they need to do with it. I've been programming since long before there was windows, and I have NEVER had that good experience. In my experience, it's always been true that windows slows down (clogs up) over time, requires additional software to keep it running acceptably, requires virus/spyware/adware protection, and that a BSOD is an uncommon but familiar experience to nearly all windows users (especially programmers). My best experience so far was my wife's computer several years ago. She bought antivirus sw and a mail program, never ran IE or Outlook. Used OpenOffice. Installed/uninstalled nearly nothing after that. Surfed. Emailed. Played PySol. It was good for a couple of years until I installed some dev software, after which it slowed down and got wonky. I learned to leave her computers alone! Recently, she converted another windows laptop to Ubuntu to ...

Names changed to protect the innocent: // Adds Sessions which fit in specified date-time range private void ReadSessions() {

It is a tempest in a teakettle, to be sure, but among the points of friction and discovery today was one about the use of the letter 'u' as a variable name. The case in point was a nice, small function, not much larger or more complex than this stupid example: public void Whatever() { User u = new User(); if (u.hasSomeAttribute()) { u.setSomeValue(); } } The focal point is the letter U as a variable name. Because of my involvement in a particular book project, I was summoned into the conversation and carried half of it for some time. I would rather see "user" than "u" because of my rules about pronounceable, grep-able names that don't require any mental mapping. That is my preference. Therefore, I can clearly NOT choose the variable name "u." I also have publicly stood by James Grenning's assertion that the length of a name should have some correlation with its scope...

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 ...