Thedwick

You many have heard of the concept of “Next Action Lists” which are a part of the Getting Things Done methodology. I don’t really use the methodology, but I do use something that vaguely resembles the Next Action part of it. And I’ve found that a really useful Next Action is just looking up people’s phone numbers and writing them down.

Imagine this item is in your todo list:
–Finish Functional View diagram for Currency Trading system

And for the sake of argument you have that item in a vanilla Outlook Task.

As part of creating that functional view, maybe you need to call three different people and ask them some questions. I’ve found that often just having to look up those people’s phone number is a big enough excuse to make me put off that task. It’s stupid, I know, but it’s just the way it is and I bet there are lots of people out there just like me.

So, I’ve gotten in the habit of making this my Next Action:
–Look up the phone numbers of everyone I have to call and put them in the Outlook Task.

That’s a really small action. It doesn’t have any of the mental baggage involved in preparing yourself to (gasp) actually talk to another human being. You don’t have to think about what you’re going to say or ask, or if that person likes you, or if they’re in town or out on vacation, or where you’re going to write down what they say, or anything. You just have to look up their phone number and put it in the same place where you’ve recorded your task.

That’s it. But here’s the genius: six times out of ten, I’ll look up the phone numbers, write them down, and then immediately pick up the phone and call one of them. There’s something about those numbers staring you in the face that’s just too inviting. Try it out!

I’ve had comments disabled for a long time because I’d gotten tired of the torrent of comment spam begging for moderation. But today I decided to turn them on, and to add a neat WordPress plugin called Challenge, which will ask you to solve a math problem in order to post a comment. It’s configurable to ask any question I can dream of, so I will eventually have to think of something witty to have it ask instead.

Enjoy.

I’ve written before about what I call Decision Algebra. Here’s a post from Rob Walling that’s (very) roughly the same thing, but from a different angle: quantifying the cost of indecision.

The executive summary? In his fairly unscientific estimate, making no decision is actually more expensive than making a bad one. I tend to agree.

Just stumbled across this post arguing that working more than 40 hrs a week is actually counterproductive in the long term:
http://www.igda.org/articles/erobinson_crunch.php. Unlike other articles I’ve seen on similar subject, this one seems to be well researched and cited.

Day 4 I was surprised to run into someone else from my company here. He’s our resident test driven development advocate and had hand-picked Thursday because it had so many classes about it. The man can do truly unnatural things with JMock, and I mean that in a good way.

We started the day with a session on TestNG by Alex Ruiz. Our project is starting to reach the limits of JUnit so TestNG seems to be just what the doctor ordered. Some highlights:

• It’s annotation based instead of inheritance and naming convention based.
• It allows arbitrary grouping of tests together
• It allows you to specify dependencies between groups and methods
• It’s easy to write setup and teardown methods for suites, tests, classes and methods
• It has a “JUnit” mode that lets you run existing JUnit tests alongside TestNG tests

Something else interesting I didn’t know before: JUnit re-instantiates your test class for each method it calls. So if you try to use a class-level instance variable, it’s not going to work. Not that you should anyway, but there it is.

Next we went to a session on emergent design through test driven development by Alan Shalloway. This class was awesome mostly because it gave me some ammunition to support a point I’d already been trying to make at work. Specifically, that one of the greatest benefits of test drivien development isn’t that you end up with tests, but that having to think about the tests first automatically leads you to good design, even if you’re not a good designer. He walked us through an example where just keeping testability in mind caused you to create an extensible and maintainable design.

Next we went to a class called “Advanced TDD”, but really all it was was a guy from Siemens talking about why he thought TDD was good. Really, we get it by now or we wouldn’t be going to a class called “Advanced”.

Also, I forgot to mention yesterday that I saw a presentation by Amazon about their S3 storage, EC2 “compute cloud” and their reliable messaging offerings. They sound pretty awesome, in particular EC2 charges only 10 cents per hour. That’s an entire server for only 10 cents! Great for times when you demand is really peaky and you need to scale (and de-scale. Is that a word?) very quickly.

It’s been a stop-and-go day today. I had to do a 2 hour conference call in the morning, exactly during an “Agile development with, or despite, a global team” session which was a bummer because I was looking forward to that one.

I did make it to a hands-on, rapid-fire session on test driven development with Ruby on Rails by Kevin Clark. It was a great class, and I was especially happy to see just how much TDD had been baked into Rails from the start, from adding useful assertion methods, to database fixtures, to a pre-canned build file that runs tests by default (rake), etc, etc.

I went to a patterns session that was supposed to be about combining patterns together in groups, but started with so much elementary pattern overview stuff that I lost interest and left. The best thing I got out of that session was a reminder that a pattern is a problem, a context, and a solution *all together*. Trying to just pull one of those out on its own is not nearly as useful as considering that triplet together as a whole.

I also briefly went to a session on open source as a business model. Lost interest in that pretty fast, too, but I did come away with a real appreciation for how painful the proliferation of slightly-different open source licenses is for anyone who has to try to understand them.

I tried to post this yesterday, only to discover much to my embarassment that my domain registration had expired last week. Oops.

Anyways, I’m back at SD Expo, which is what started this blog in the first place. That first experience is what helped push me in a different direction in my career, away from pure management and back into hands-on technology.

Two disappointing changes from last year: the bean bag chairs are gone, it’s impossible to find an open electical outlet, and the (free) wifi is unusably saturated. On the other hand, some of the talks are exactly the same, at least in title, to talks from 2 years ago. Many are new, however, including an entire track for Ruby.

Yesterday, I went to a service oriented design talk by Michael Rosen in the morning. The most interesting thought that came out of that for me was the idea of dividing your services ecosystem into two tiers: a lower-level tier of utility and integration services, and a higher-level tier of business-level services. For example, you might have an Authorization service at the utility/integration level, or a facade for a legacy system at the utility/integration level, but you’d have a “Booking” service at the business tier. This allows you to make different choices about things like transport mechanism and granularity at each level. It also allows you to keep your business services level ‘pure’ and isolated from compromises you must make when integrating legacy systems.

In the afternoon, I went to a Java Security talk by Allen Holub in the afternoon. I’d hired Allen to do an object oriented design class at my company a couple of years ago that I thought was really good. His talk on security was pretty good too; the most salient thing I got from the talk is that the Java security apis really are hellishly complicated, it’s not just that they look that way. Previously, I’d thought that it was just because I didn’t “get it.” But in reality, they’re just too complicated, as I’ve found is the case with many Java APIs. For example, just as the connection string in JDBC contains a lot of vendor-specific parameters smashed into an ugly string, the factory methods in the security api also do.

Today so far I went to a domain specific language talk by Juha-Pekka Tolvanen. This one was one of the sessions I was especially looking forward to because it seems like such a big and obvious win. I came away from that talk with a good link to DSM resources, but with the disappointing news that where these languages tend to be the most successful is in embedded and product markets (like cell phones), where a vendor churns out lots of variations on the same basic product line. There was one example from an insurance company, though, so there’s still hope for me.