Agile Otter Blog

There is a clever feature in bash, in that you can do a lot of manipulations while accessing a variable. Note that I always use "clever" in a pejorative sense, but while this is clever (argh) it is also helpful to me. I find that I, like all users, will tolerate a little cleverness if it gets my work done. In this case, it's the substitution features that get my attention. For variables: ${VAR:-zzz} returns $VAR, or "zzz" if $VAR is empty ${VAR//x/y} returns $VAR after replacing all "x" with "y" ${VAR:=zzz} returns $VAR or "zzz" if VAR is unset, and assigns VAR (ick) And of course the coolest version is the $() operator (AKA: command substitution), which used to be done with ugly backticks. This runs a command and returns the output of the command into a variable: $(echo $fname| cut -d. -f1) $(echo $(basename $fname) | cut -d -f1) Which leads to this kind of "clever" coding: dest=${DESTDIR:-/tmp}/$(echo $(basename ${sourc...

From the XP mailing list, James Grenning has this to offer: > There are two values to software > 1) Business value delivered > 2) Ease at which the next important feature can be delivered

A common question on the TDD and XP mailing lists is how to get managers to approve refactoring and testing. The standard response is to ask in return why programmers need permission to write code that doesn't suck. The problem is that it is hard to know how to manage software development in a condition of rising Technical Debt . I was a programmer a long time before doing any management. I had to learn to manage my unit of work, to do things people wanted to have done, etc. There is a certain amount of professional discipline necessary to be a good employee-programmer. I had a tendency to do X (which was required) and throw in some Y and Z. Where Y and Z were simplifications along the path to doing X, it's all good. This shouldn't need permission (one would hope) but what about when they were solving miscellaneous potential problems on the side? What if they scratched an itch? Under the reign of SAS70 interpretations and ISO 900x dreams and basic risk management, I...

I had a small task to build a subversion post-commit trigger. I didn't know my way around the subversion library, and so I started spiking... the old way. I fired up an interactive session and tried playing with it. I created a repo by hand and started running merges and copies and checkins, and had the trigger print stuff out. There is Nothing wrong with doing that, by the way. The problem was that I didn't toss it out and TDD the new one into existence. I TDDed my way through any new routines, and extracted-n-tested any tricky bits until my main loop was much smaller, but I didn't toss it and TDD it back into existence. I kept the prototype. As a result, I have this code that's pretty simple and nice, and there in the middle is this post-coding-tested wart. It works, it passed code review, but I'm not going to put this one up on my fridge. The routine has a triply-nested loop and is at least a dozen lines long. It's disgraceful. Worse yet, the tests...

I'm becoming an Esther Derby fan, partly because of her statements about employee motivation and demotivators. . I became acquainted with her work through an agile toolkit podcast in which she was originally invited to discuss retrospectives and making them stick. The conversation turned toward motivation and demotivators, and now I have to go buy some books. Better yet, I need to make some changes.

... is "pair". Just had a good pairing session. Our result is small and simple, probably not enough to justify our time if you counted lines of code, but involved lots of learning and navigation and refactoring. It was a lesson in doing less. I was in a bad mood earlier, but a good pairing session with working tests can change my outlook on the whole day. Wish I had one of these at 8:30 this morning! Collaboration and production give me energy that other tasks can take away.

We've had some upheaval and change with RIF and new directions. There are essentially three projects running now. One is for data management and product support relief, one is for performance improvement, and one is a new feature that is expected to provide crucial value and income for the company. We also have a very small project going to lower costs and improve accuracy of some important financial data transfer with external parties. What is going well: These really seem to be the right high-value things for us to work on. Customer involvement is up. Each team has direct contact with the people who will benefit from the feature, or a reasonable (set of) surrogate(s). Those who "get it" are beefing up their code-test efforts. I can't really say they're doing TDD properly, but there are ATs first and usually there are UTs written in the course of the work. We'll get there. Amongst certain team members, pairing is up. I'm able to spend more time on t...

The XPairTise Eclipse plugin is supposed to enable remote pairing, but the server is hard-coded to use "tcp://localhost:61616". Localhost? How am I supposed to do remote pairing when the pairing server is bound to the loopback address? Are other people modifying the code to a fixed address? Does that make sense to anyone? I guess I can download the project from version control, create a version with an option for the port to listen on, roll it into a new jar, and copy that into the directory where I start the app, but it would seem that nobody could use it as-is. No? Am I missing something?