Kevin Klinemeier's Blog

My blog is moving locations

2011-02-14T11:26:00.000-08:00

My blog has changed locations! The folks at Pugetworks have been great to work with and I enjoy being part of a group of writers. I've moved over some of the best content, and written some new articles, collect them all at:

http://pugetworks.com/author/kevin/

-Kevin

Relative estimates are like a stagecoach

2010-02-02T11:44:00.001-08:00

If you're having trouble getting across the idea of relative estimates (story points) vs velocity to your management, try this approach:

Estimate stories using a distance measure. Furlongs for fun, miles if you're a boring American, kilometers if you're a boring person on the rest of the planet.

Your team velocity is measured in furlongs-per-sprint. This makes clear the separation between how much work needs to be done and how fast a team can complete it. It calls out the knobs that management can turn immediately: go faster, do less work.

For the vehicle, consider a stagecoach. Every new horse added to a stagecoach adds to its potential speed. Four horses is better and faster than one horse, but not four times better. There's a point where you're better off with two stagecoaches.

Breakdowns:

Another popular analogy is rocks-in-a-box. Your velocity is called capacity, and described as a box for the Product Owner to fill with rocks. Rock size is estimated by the team. Lots of small rocks do a better job of filling up the box. This point, that small well-understood stories are easier to complete, is missing from the stagecoach analogy. (If the miles are short, they go by faster? Doesn't quite work.)

Questions to ask when you want something

2009-11-09T16:36:00.001-08:00

Can I have it now?

No.

Can you tell when I can have it?

No.

When can you tell me when I can have it?

I don't know.

Do you need something from me?

No.

Bullshit.

Maybe this should be a flowchart.

Testing with Moxy

2009-08-26T12:31:00.000-07:00

Overview
Build proxies that pass through most requests, but create mock results on well-known data.

Our situation
We needed to be able to verify the behavior for error conditions from our Selenium (web) tests. We had already created mock services that would return these results. We then had to manage when we connected to which endpoint, which put the expectation about behavior outside the test and in the server configuration. In order to do a single regression pass, we had to stop and reconfigure the server.

Our solution
We created Moxies (mock proxies), which most of the time are just a plain passthrough to the real endpoint from our vendors' test systems. For a well known set of data (addresses in Broken Arrow, Oklahoma) the Moxy returns error conditions. Those addresses and their expectations are defined in a single class, shared both by the Moxy implementation and the tests.

Benefits
Test real success and mock failure in same server configuration.
Data and its expectation is in sync (shared classes).
Code is explicit about which tests depend on which Moxies, and which specific behaviors.

Future
With the same solution we expect to create a set of test cases that do not rely on the availability of the vendor test systems, based on similar conventions. (Eureka, CA)

Other implementations
We considered using wrapper objects injected via Spring to accomplish the same thing with less monkeying around with endpoints. This would avoid needing to deploy a real http mock service, and avoid issues around certificate verification and authentication. However, an injected solution would require deploying the mock software on all the client machines, and tweaking its configuration so that the wrapper bean is injected in our test environment, but not production. The injection solution also doesn't test the parsing of the error response, though that should probably be done in unit tests anyway.

If we were using a ESB like Mule, we could have configured Mule to redirect the requests based on the data, and used our mock services unchanged, and the test system configuration also unchanged.

Some solutions avoid having to use key data in the request object by manipulating http header info instead. This wasn't an option for us, unless we create some kind of signal for that header all the way through to our public pages. That seemed too invasive for our situation.

Closing
It works for us, and has a cool name*. What more could you want?

* Yes, you could probably more accurately describe this as a decorator. But Mockorator isn't nearly so awesome a name.

Leading Self Organized Teams

2009-08-03T23:58:00.000-07:00

Self Organization, Collaboration != Fire Your Leadership

One of the questions I've tackled with the agile teams I've worked with is how to find a balance between the need for direction and quick decisions with the open and self-organizing approaches that are recommended for teams practicing agile processes. A lot of this perceived conflict comes from people overstating the basics. In particular:
Self Organization != No Leadership. Collaborative Approach != Everyone Votes On Everything.

Core Values:

Self Organization: Invite owners and participants rather than assigning people to teams

Transparency: Discuss topics openly, rather than among a separate team.

Collaboration: The point of the self-organized group

Direction: The owner is responsible for driving to dates, providing major guidance (sometimes from above), and deadlock resolution.

Review: Periodic review of practices and applications is key to success.

Example: Spacely Sprockets Quality Issue

Problem: All the sprockets we've got are throwing NullPointerExceptions.

The Development Director in this case wants to delegate this task to the team. In order to do that, she asks for volunteers to be the "owner" for this issue, and Olaf steps up. After consulting with the Development Director for parameters (due dates, budget, etc) the first thing Olaf does is send an invitation: (Self Organization)

To: yourWholeTeam
Subject: Spacely Sprockets Quality Issue
Hello Team,
We need to determine whether to stay with Spacely Sprockets, change to Cogswell Cogs, or pursue some third option. if you're interested in participating, send me an email and I'll include you in tomorrow's meeting.
-Olaf

The group meets a couple of times (Collaboration), trades emails (via whole team mailing list, for Transparency) and works towards a recommendation. One participant suggests Gary's Gears, but Olaf shares that Gary's Gears are outside the budget for the project. (Direction). Absent of that option, the group finds consensus on staying with Spacely after an impassioned speech by George J., one of their salesmen. Olaf shares that recommendation with the rest of the team, then the Development Director, who puts the recommendation into place after a few additional questions/clarifications (more Direction).

Common Problems

Self Organization Problem: nobody signs on

Often you'll be expecting "the usual suspects" to show up when you invite people to collaborate. Sometimes you'll be surprised to find no responses to your hot topic. As the owner, this gives you the opportunity to find out why. This may be for many reasons:

People are busier than expected
People are tired of working with the issue
People feel that the solution is obvious
People feel that the recommendation won't result in change.

What to do:

Talk to your usual suspects with these possibilities in mind. The major advantage of the process in this case is that as the owner you are aware of these problems at the beginning rather than the end of the process.

Self Organization Problem: everybody signs on

Instead of "the usual suspects", you get the whole department. Reasons for this include:

Concern that some aspects of the issue are being ignored or are unknown to the group
Concern about "the expected outcome"
Size/Impact of recommendation

What to do:

Hold a first meeting and have a round-table where you invite each participant to share what motivated them to participate.

People who feel that they're alone in a concern have an opportunity to share it, and can hear others if they exist. Those who are worried about an "expected outcome" can share their point of view. If the source is that the impact of the recommendation is huge, then team members have an opportunity to voice general concerns and witness for themselves the process by which the recommendation is being made. Sometimes just having the preliminary session is enough -- the team can identify when enough of each viewpoint exists and will drop out satisfied that their viewpoint is represented.

Another approach is to assure the team as a whole that there will be an opportunity to review the recommendation before it is "ratified." This can make team members feel less urgency about allowing others to tackle a difficult or contentious issue.

You may be tempted as the Owner to be aggressive in this case about reducing team size. Be sure that you are keeping in mind that the real goal is not to simply make a recommendation, but to have it understood and implemented by the entire team. To this end, it may be more effective to allow for some up-front "inefficiency" in order to get everyone on the same page and reach the real desired outcome faster as a result.

Direction Problem: small project

Sometimes this all seems like a lot of effort, with more time spent sending invitations and setting up meetings than it would take to do the work.

What to do:

Use IM and/or email for self-organization. Set a deadline for response (self-organization), and list your planned actions by that deadline (Direction, Transparency). Ex:

To: yourWholeTeam
Subject: I hate the PMD "use if x==y not if x!=y" rule
Hey all, Can someone tell me why I shouldn't hate this rule? If nobody objects, I'll remove it on Wednesday.
-Developer Danielle

Collaboration Problem: can't reach consensus

Rational people can disagree on a subject. Time doesn't always allow all avenues to be examined.

What to do:

This is the "big job" of the owner. It's the owner's responsibility not only to identify when it's time to just make the call, but to also make all the participants feel that they've been heard even if they haven't been agreed with.

Every time the process is used without the need for this outcome are like money in the bank. That money (trust, really) is expended in these situations. If you've got a positive balance, then this is just a a problem. If you're overdrawn, then this situation can become a fiasco. Team members must feel that the situations where the owner makes the call without consensus are rare, and due to issues that are a toss-up, or due to outside pressure. If you're doing a lot of this, it's probably an issue that should be considered in the process review.

Transparency Problem: When should I include everybody?

Is copying yourWholeTeam on *everything* really the recommendation? What if they're unlikely to care and it's just noise?

What to do:

Use a restating of the golden rule to determine what to send to the whole group: If you weren't an active participant, would you want to know about this part of the discussion? Err on the side of Transparency.

Criteria For Review

These criteria help determine success of this approach and your specific practices:

Does everyone feel they understand the approach?
Does everyone feel that quality recommendations are being made?
Do team members feel involved, not dictated to?
Are recommendations timely and within expected parameters, ie conforming to Leadership's direction?

Last Words

To restate a problem from above, it's important to keep in mind that the end goal isn't a decision, its a decision whose spirit is implemented and upheld team wide. I use this approach not because it makes everyone feel good, but because it's the most effective way to get real results.

Rails Hates me

2009-04-15T00:52:00.001-07:00

So, I've got a little extra time, and I figured it was time to get back to my rails project. I've half written this character-timeline-thingy maybe three or four times but never quite completed it. As I recall, I had it almost-completely-working maybe a year and a half ago, so I thought I'd take it out for a spin on my new macbook with its built-in rails mojo.

I grabbed my old files off of my external hard drive and: No love. No mysql. Oh, of course. Installed mysql and a visual editor, felt warm and fuzzy about that process. Created the tables with the table-creation script I created when I used this last time, made another mental note to look into rails' migrations and

$ rake...

Fail. My tests are talking about fixtures that have some kind of problem. This is fixed, and something else doesn't work, a nil where I didn't expect it. Oookay, bwuh? Maybe this is just old and I'll start over. It's got deprecation warnings in it too, so meh.

$ mv timemachine timemachineOldAndBusted
$ rails timemachine
$ rake

Fail again. The mysql gem isn't installed by default anymore. Okay, so:

$ sudo gem install mysql

Fail again. some crap about headers and native extensions. I turn to google, and go through a lot of gymnastics around installing stuff from source, upgrading gems itself, etc. etc. I follow all the directions I see in a pretty helpful article, everything seems to be passing and:

$ mv timemachine timemachineFail
$ rails -d mysql timemachine
$ rake

Fail. Now it says that the mysql gem isn't installed, but gem list says it is. Back to google, now the suggestion is to do some trickery with 64-bit mysql vs 32-bit mysql and binary hacking the broken mysql.bundle file to fix the problem.

This all feels like why Java and platform independence is still important. I'm tired of mucking with building from source into my operating system. AppEngine supports Java, right?

Easy self-improvement

2009-03-25T13:27:00.000-07:00

What's the easiest thing you can do to improve yourself? Take a compliment, and make it twice as true.

What's your favorite compliment of all time, or of the last year? Chances are, your complimentor has identified something that comes easily to you, a natural gift of yours that was appreciated. It may be more valuable to improve something that you're already pretty good at than try to rebuild yourself in something that is difficult.

Let's say it's some mode of communication, maybe written communication. Where else can you use this skill? How could you be even better at it? What is it that makes you good, exactly?

These kinds of questions, when asked about something you're already doing well have a much lower "effort." If you've picked an area you're good at, that you're excited about, you may find that they return energy to your day instead of subtract it.

Cut n Paste to lower communication barriers

2009-02-09T10:12:00.000-08:00

At work, we have a weekly newsletter. I used to read it, but I don't anymore. It used to just be in email, and I'd skim some of it as it came by before I deleted it.

Now, it's a document attached to an email. It requires just one more click to see it, and I don't do it. It had some nice information in it -- new hires, birthdays, other company news. Stuff I could read "incidentally". Clicking that link feels like committing to reading the whole document, rather than just skimming over what's already in my box.

I've been thinking about how I can lower barriers when I communicate as well. The easy one is that instead of just mailing a link (which most people won't click on), I paste the whole document into my email.

The same thinking has led to a lot of physical printouts in our office. This strikes some people as funny -- we're a tech company, yet much of our process is documented on giant sticky notes. Yet the results are clear: a giant sticky note next to the fridge communicates much more effectively than email, or a diagram in a folder in Sharepoint.

But what other barriers exist in our group that I'm not aware of? We've worked pretty hard to reduce them: we move desks when we reorganize teams so members can sit together, we aggressively encourage pair programming, our scrum process has its standups, etc.

A better question might be: how do we identify them? I'm not aware of a metric that I can rely on. Things come up in the retrospective, but that's just once every three weeks. Perhaps the real story here is about using all channels of communication.

In my email example, I have only one channel so I need to make sure it's as effective as possible. Even then, I don't really expect everyone to get the information I'm sharing.

When I give presentations, I try to say my point three times, and in three different ways: Once in text, once with a picture, and once verbally. Maybe there's a correlation there when I'm looking to drive change in our office (or just hold us to changes we've already agreed on): A poster, an email, and a verbal reminder during standup.

I'm going to look for things where I'm using only one mode of communication, and either reduce my expectations around that message or increase my modes. (make a poster, send an email, include it in our standups)

Scrum Baseball

2008-09-16T17:45:00.000-07:00

When talking about Scrum, the question often comes up about "customization." Each team is expected to customize things to their environment. But when you're adopting it for the first time, how far is too far? I've heard other analogies surrounding baseball, here's mine:

What is baseball? Softball is still pretty much baseball. T-ball is still pretty much baseball. What about Cricket? While it has bats and balls and running around, it isn't baseball.

My "short list" for scrum is:

Work is stack ranked in a product backlog, sized relatively
Work may begin before product backlog is "complete"
Work done in iterations
Daily standups for status

Code Coverage for Eclipse redeux: EclEmma

2008-01-08T14:28:00.000-08:00

In a previous entry, I lamented that I couldn't get instant feedback for the coverage results of my unit tests in eclipse. A coworker (David Koontz of SolutionsIQ) pointed me at EclEmma. In a nutshell, it works.

It gives me line-by-line coverage, highlighted in green, yellow, and red like the coverage reports I get from Cobertura. In addition to file-by-file coverage, EclEmma also summarizes coverage reports for an entire project in an Eclipse view much like the Cobertura's roll-up behavior.

It plugs into Eclipse smoothly via update site, and works with all my tests including configuration details with Spring, Hibernate, HSQL, etc. Usage was simple: if I had a JUnit execution defined in Eclipse (generated automatically via runAs .. unit test), then I can reuse it with EclEmma. Run As ... Coverage Test is also available.

My only complaint is some strange behavior around code that throws exceptions. If a block of code throws an exception partway through, EclEmma counts that entire block as untested. The authors point to this being a limitation of the Emma code coverage tool. My code doesn't generally throw a lot of expected exceptions, so it hasn't been a major issue.

In general, happy as a clam am I!

Integration Testing more important than Unit Testing

2007-08-29T09:23:00.001-07:00

When I'm learning a new framework, strict unit testing isn't very helpful. To illustrate, here's an example:

I want to write a command object of some sort that interacts with jbpm. Jbpm is a workflow engine, with nodes and transitions. I need to look up a process (a collection of nodes and transitions), select a node and tell it to take a particular transition.

If I use EasyMock to ensure that I'm testing only my code, I can test whether the code is doing what I expect. However, that doesn't answer the most important question: Am I doing this the right way?

In my example, there are a couple of ways to look up nodes, and a couple of situations where the framework behaves differently than I expect. I can't find any of that until I do integration testing.

The paradox is that the authors of the framework don't have questions about which approach in their own framework is the correct one. Hence, testing integrations with the framework isn't attempted, and anything not attempted isn't factored into the design.

Bottom Line: Easy integration testing is key for rapid framework adoption.

Eclipse instant code coverage?

2007-05-30T11:40:00.000-07:00

In general, I've drunk all the test-first kool-aid there is. My development is a constant cycle of write test, run test, write code, run test. Repeat until I think I'm done.

I really like code coverage tools, as they let you know if you're as done as you think you are. Are you testing that else clause or that exception case? Good stuff.

So why can't Eclipse show me which lines were covered by my *last* test run? I think that would be pretty useful, and it seems like the pieces are there to make it happen.

The Deal with Documents

2007-05-22T10:54:00.001-07:00

When working up some process documentation, our group had a little bit of a revelation:

Documents exist to make a decision.

This single statement really helped us streamline what we were doing with our documentation, and our process itself. At each stage, we asked "What decision is trying to be made? What information is needed for that decision?" Everything else was junk, and we cut it out of the document.

Every time I write a document now, I ask myself that question.

LinkedIn end-run.

2007-04-24T13:46:00.000-07:00

I was contacted today, by phone, by Dan Payne from Opsware. He "found" my information via LinkedIn. This was surprising to me, since I don't know Dan and was under the impression that LinkedIn worked by restricting people 's access to you through their invitation approach. What I'm pretty sure happened here is that the combination of real name + company name + google was quite enough to dig up my email address and to call up my employer and get to my direct line.

I hate that. That's not the permission I gave him, and it irritates me that LinkedIn made it possible. So, I sent a note to LinkedIn customer support complaining about this inappropriate usage. I'll keep you posted with how that turns out, but it sure seems like it should be in their best interests to keep people from using them to mine other people's personal data. We'll see how that turns out.

When is a property not a property?

2007-01-26T10:31:00.000-08:00

There's a lot of talk about property support in Java 7. Some of the proposals allow you (like C#) to access the get/set methods without using the method name:

foo.bar //actually calls Foo.getBar() or a reasonable facsimile

Except now you've made a distinction between accessing it as a 'property' and accessing it via a method. What's the difference? Richard Blair says "read the docs", but I think that's the wrong answer. The language has made a distinction by allowing two ways to access code that makes multiple modifications to an object's state. If the distinction is meaningless, then it adds clutter. Any access to a 'property' needs to appear to be a method call to client code, because that sets expectations accordingly.

Always and Never

2006-11-30T15:38:00.000-08:00

The first thing I have to explain to business people when they're trying to give me requirements is that there are two kinds of "never". There's the business/real-world never, and then there's developer never. What regular people usually mean when they say never is "not very often".

In order to get the point across, and to clarify what people want when they say "never", I explain the repercussions: "Okay, you say this never happens. Is it okay if the program asks the user to contact support and then exits if it does happen?" That tends to get us to the right answer pretty quickly.

Trickier is "always". It has the same problem of being far more precice in software than it is in English. What's worse is that it's often implied or inferred in an otherwise reasonable requirement. "The software will send an email when an order is placed." Is that an always statement? Asking this question can be very illuminating. Typical responses can be "Well, not if there's been a problem -- then we want to call." or "Yes, if they've given us an email address".

Do (our) users want broken features?

2006-11-17T10:53:00.000-08:00

So, I've completely drunk the testing Kool-Aid. I've taken it as my personal goal to incorporate automated testing in my entire process, and have seen it work. I've had multiple releases go through QA with no functional bugs*. I preach test-first development to everyone that will listen.

The problem is that our users actually want buggy features.

This was pointed out to me by some of my coworkers in a code review where we discovered a class that was fairly complex, but had no unit tests. We talked about why this came to be, and the answer given was that if the project goes to QA but has bugs, nobody gets in trouble. If it goes to QA, has no bugs, but has fewer than expected features, then the project "slips", people panic, and we have PMs and above at our desks wringing their hands and asking "what went wrong." The pressure shifts from dev to pump stuff out to QA to give the approval. And I fall into this trap every time.

However, I've said "my users", but it isn't my users that are giving me pressure on the release dates. It's my project management. Maybe I should say:

My project managment actually wants buggy features.

For those of you following along at home, this isn't specific to my current place of employment. Now that I consider it, I think I've seen this everywhere I've worked. The only time I didn't feel it was on the two projects where we had a reputation for quality in our QA releases. I feel like lightning has to strike in order to build up this kind of reputation, and I haven't been able to make a tall enough rod on my current projects.

What's worse is that we clearly increase the amount of time between when the bug is written and when it is discovered. That means the bugs take longer to fix, which ultimately means that the project takes longer, even though we've "hit our dates." This is clearly because there's an expectation of a long time in QA that can't be well estimated.

I think the Agile folks would suggest that the problem is with "QA resources" in general. I have a tough time letting go of that specialization. Test plans are difficult to write well, and even more difficult to execute with consistency and an eye for detail.

Maybe the right answer for us (if this can't be addressed by talking to the various date-concerned entities) is to not expose a QA handoff date, but incorporate QA into the dev team itself as partners in the ultimate deliverable date. XP would seem to suggest this as the way to go. We would have more flexibility (agility?) in giving sections to QA when they're testable, and optimally we could even test things earlier in our cycle than we currently do.

I worry that some parts of the team leadership may hyperventillate at the idea that there isn't an official QA handoff date that they can track and put a checkmark next to, or put less snarkily, have less information with which to schedule QA resources.

I still don't know if I can reconcile those needs, but I know that I don't like the behaviors that the current process encourages.

* functional bugs are what you get when QA says, "should it do this?" and Dev says, "oops, no." There are tons of other kinds of bugs, like usability issues or miscommunication issues. Most of those aren't addressed by automated testing.

Phidgets: the Beginning

2006-11-14T23:36:00.000-08:00

So, I'm a total hardware n00b. I've written software for a decade, and happy talking about inheritence, encapsulation, polymorphism and tossing around newer buzzwords like dependency injection and all that.

But I decided to start a hardware project. I'm not going to give away the ending, mostly because I'll probably never get there. Remind me to tell you the story about the coffee table I was going to make once.

Anyway, I bought an 8/8/8 Interface Kit from Phidgets.com. It's a smallish thing, about the size of a deck of cards, and about a hundred bucks delivered. It's designed to pass inputs and outputs through USB to a computer, where software running there actually makes the decision about what to do when. Plus, one of the hojillion languages they support is Java, so that feels right at home.

I've got the thing on my desk now, and am installing the software. Except it needs the .net framework, blah blah blah. It's nice enough to redirect me to the download page, and after getting confused about my 64 bit proc but 32 bit operating system I'm good. That done, their software installs fine. While .Net was .downloading I got eclipse set up with their Java examples, and once the software was installed and the device connected their InterfaceKit example ran right out of the box. Granted, I have nothing hooked up to it, so I don't know if it's doing anything, but it prints lots of stuff to the screen. I grabbed a wire and jammed it between the ground and the different inputs, and successfully made stuff print to the screen. Cool!

Next up is outputs. For that I have an LED that I clipped off of a defunct printer screen. I'd have desoldered it, but Nicole just bought the desoldering iron, and I wanted her to be the first to use it. I hook it up, and nothing happens. So I hit their website, which has the "n00b manual for InterfaceKit", which is six pages long. I've read manuals that are 20 pages and have less useful information. There happens to be a section on "hooking up LEDs to your InterfaceKit", and by section I mean a page. It mentions anodes and cathodes. Which I look up on wikipedia, turn my LED around and it works.

Sort of. I've written my own software to turn input #1 on for 2 seconds, then off. The LED responds by shining bright and steady in the "on" state, but instead of being off for the "off" state, it flashes. I vaguely remember that "digital" outputs have some kind of square wave mojo going on below a certain hobgoblin threshhold or something, but all that information is eleven years old, and there is a lot of beer and parties standing between my CE 101 class and today's attempt. I also suspect that the answer is actually on the LED page of the manual, but again too much inebriation between those symbols and the present day.

So, I've got a flashing LED. The software has been fairly straightforward to this point, and while they don't release the sourcecode to their Java libraries, they do have a reasonably well written Javadoc. Moreover, to this point things are written in a pretty straightforward manner. To turn the LED on and off, I've written these lines:

interfaceKit.setOutputState(1,true);
interfaceKit.setOutputState(1,false);

(with sleep statements in between)

So, I'm reasonably sure I haven't screwed that up. I even have system.out.printlns in between, which of course make me feel dirty, but I'm ignoring that for now.

I'm not the only hardware n00b connected to the global inter-tubes, so I sign up for their forums. I could complain about the way the forums insist on mailing me a generated password as though I'm going to be doing stock trading on this thing or something, but that's really just sniping at this point. I shut up about the password thing, and enter "flashing LED" into the forums.

No luck there, I think now that the problem has to do with the shoddy wire I'm using (cut out of an old phone cable, stripped with a kitchen knife, and not a solid wire but twisted copper). I changed the LED to another output, and this time off was off, but on was flashing. I went to change it again, and dropped the LED off the end of the wire (I just had it wrapped, not soldered or anything), and have decided to declare that to be the problem, and call it a night.

Next time: wire strippers and real wire!

Dead Horse: Checked Exceptions

2006-10-30T18:09:00.000-08:00

I'm reading "Beyond Java", by Bruce Tate, and he complains as many have about checked exceptions. I've never understood this complaint, and I don't want to say that it's because I understand how to use them and all these smart people don't, but I'm about to.

I like checked exceptions, they keep me honest. Tate asserts in many places in his book that the few actual problems that static typing catches would be caught with unit tests anyway, but this seems like a case where you can't make that argument anymore. In the unit tests I write and read, failure cases are the least well handled.

Tate (and others) asserts that checked exceptions are invasive, and continues to say that most of the time you can't do anything but throw it, so you're always throwing them, and eventually you just ignore anything you read that has exception in it.

He's right, about that part. The problem that I see is that it's never led him to used checked and unchecked exceptions together. Here's how I evaluate whether to handle, re-throw or convert an exception:

1. Can I handle it? Obviously, if I can, I do.
2. Will callers be able to handle it? Then let them.
3. If callers can't handle it, is it imperative (due to data corruption) that callers be aware of this situation?
4. If none of the above, turn it into a Runtime Exception.

These questions are asked at integration points, like the barrier between a webapp and the database, a property loader and the filesystem, or a utility program and a webservice. If we had no checked exceptions, I feel pretty confident that I would fail to consider all the potential failures in these integration points, and have far less robust code as a result.

Selenium rocks the house

2006-10-27T17:11:00.000-07:00

I'm so impressed with Selenium. The browser integration and the IDE true/false makes it very easy to set up and use. I literally got it working in about ten minutes. I had a couple of bugs from QA, so I used Selinium to record their replication in my dev environment, then switched a couple of attributes from "off" to "on" to represent what the code *should* do. And now I'm back to automated test-first programming.

I see that with the Selinium RC server, I could actually run these things as Junit tests, or I can run them with the selinium suite. I'm torn as to which way I want to go. Obviously, recording them via the Selinium IDE is the way to start, but being able to make modules in Java code sounds pretty powerful. Once you go to Java, though, you don't go back to the IDE, so I'm worried that will make it less flexible in terms of using selinium tests to communicate with the QA department.

I'm sure that the QA department can learn to use this tool -- they've learned far more byzantine automation tools in the past. A frequent problem we have is in communicating with the folks that do our acceptance testing. They're a hand-picked subset of our actual users, and it's often difficult to communicate unusual situations. The type of bug reports we are typical of non-technical bug reports, basically "got this error" without a lot of information of what happened before the error happened in the first place. That's not their fault -- they're likely not thinking about what they've done before, and in many cases the problem is so complicated or convoluted that they can't realistically be expected to remember.

The thing I'm really wondering is if Selinium is simple enough to be used by our acceptance testers to help articulate what they're seeing. Could we really ask them to just record their session, and playback their experience? That would be pretty exciting.

So much less spaghetti code?

2006-10-24T14:37:00.000-07:00

I talked to a Rails proponent today, who mentioned that he was very tired of all the spaghetti code he was working with in his current development language (Java), and said that working with Ruby and Rails was such a relief. He espoused this as an attribute of Ruby itself, that it didn't create such spaghetti code.

I, the skeptic, suggested that the spaghetti just hasn't been cooked yet.

Rails and the SOA

2006-09-06T17:03:00.000-07:00

In a nutshell, I'm told that one of the great things about Rails is that you don't have to do all this middleware work to access the database. It gens up objects and they Just Work (tm).

Other people talk about how great middleware is: Create your Service Oriented Architecture as though the database doesn't even exist, and interact with it that way. Do all the ugly database stuff for the back-end of that.

Is the upshot of this that you should write middleware with Rails?

Please choose the site closest to you, because our site is stupid.

2006-08-02T12:08:00.000-07:00

Why do websites and download tools continue to ask me to choose from a badly-sorted list of locations to decide where I should download from? Sourceforge and Eclipse both do this. They're completely capable of asking (and in at least Eclipse's case remembering) where I am, and choosing a site from there.

Otherwise, I'm left staring at a huge list of locations, some of which are ridiculous (Tel Aviv? I'm sure I've got a hot connection there), and others are unknowable (UMP? What does that mean?).

The whole idea of online updates is that it's easy. Adding these user-unfriendly steps kind of defeats that purpose.

Nice goal, what's your plan?

2006-06-27T12:51:00.000-07:00

Scott Berkun writes today that, in a nutshell, personal goals are amorphous and weird. He points out that in order for them to be useful, they have to be measurable and specific. But that's not what goals are. If you ask someone for their life goals, they'll say things like "retire by 60" or "own my own home" or somesuch. That's not measurable until it's done. The illuminating followup question is, "What's your plan to reach that goal?" If you're talking about your life, and you don't have a plan to reach that goal, then you're not gonna. The same is true for career goals.

Let's say your goal is to "master Hibernate". That's a nice goal, but not at all measurable. Plan items might be to:

Read a particular book on Hibernate and give a presentation.
Answer (correctly) at least 7 postings in the Hibernate forums.
Apply skills above to map a bidrectional many-to-many relationship.
Research transaction options and give a presentation/recommendation.

Goals without a plan aren't goals, they're just hopes.

Threading .. the next revolution

2005-06-06T11:09:00.000-07:00

I've been thinking for years that the next major language/runtime improvement to follow automatic memory management is automated synchronization. Not the heavy-handed top-level "synch all" but something that is smart about what needs synchronization and what doesn't. It will have to know about deadlocks and stale reads, and atomicity violations, and prevent them all with reliable accuracy.

Why this, and why now? It seems like a logical next step after memory management, and I'm far from being the first to have that notion. In the last couple of years, however, it's becoming apparent that some of the push for this kind of solution will come from the hardware that our systems are running on. Industry pundits have been saying that single-core speeds are going to stop increasing. However, this prediction has become real enough now that multi-core single dies and hyper-threading approaches are in production. To take advantage of these performance increases, you often must change the way your application functions to focus on multi-threaded capabilities.

Tools that have some of this knowledge already exist, mostly geared towards development-time analysis. What we'll need, however, is a run-time handling of the problem, backed by some kind of language adaptation (either new features, or new usage of old features)

At first glance, this problem looks a lot like the memory allocation problem. There will be run-time tradeoffs for development time gains. It should simplify the tedious and complicated business of determining where synchronization issues are. It takes a run-time tool (memory analyzers) and turns it into a run-time action (garbage collection).

However, there's a major difference. Where many developers were willing to put up with an overall runtime slowdown in order to gain an increase in developer efficiency, that won't be the case for automatic synchronization. The entire point of automatic synchronization is to take advantage of the potential performance gains in the new thread-heavy architecture. Add to that the fact that unlike most applications, the runtime synchroniztion must be 100% (possibly needing to be provably) correct, and you have a big task.

I've said something here that needs elaboration. It is my belief that most multithreaded applications today work, but are not correct. It's been my experience that if you examine a complex multithreaded system closely enough, you are almost guaranteed to find situations where there exists the potential for deadlock or dirty-read issues. In practice, these issues "almost never matter" because of outside guarantees: "That thread never runs when this thread is running" or of timing scenarios that, while possible, are very unlikely. An automated system would not have the luxury of being lucky, and as a result will incur overhead that hand-synchronized systems will not need to handle.

Speaking of handling, what would it have to handle? Here's a list of synchronization problems off the top of my head:

stale thread information
atomic reads/writes
deadlocks
transactions

The last one is the interesting one. It's not enough to have perfect field-level automatic synchronization. You must be able to designate a group of changes as being written atomically. A classic example is a bank balance transfer. The new values in 'checking' and 'savings' must be written at the same time, to prevent any user of the thread from getting a mismatched value. I think this is where new language features, or new usages of old features, are going to drive a new approach to programming.

Of course, nothing is new under the sun. That 'classic' example of transactions is just like writing to a database. Both operations need to be done atomically to the database, so that if they fail, they fail together. Approaches from relational database programming can certainly be applied here, leading us to think of shared memory like a database. Even so, I don't think there's a standard API or approach to database save transactions currently in wide use across languages, and probably not even within any open language. Closed languages like Delphi and others may likely have a single dictated approach.

Now, obviously I'm not the first to come up with the idea of automatic synchronization. There are academic papers written 15 years ago or more on the subject. Graph theory certainly has something to say about this kind of thing, and parts of its tenets are even older. There's a lot to read even before getting started, and it's a big project.

But big projects, in the XP way, should be reduced to smaller projects. So I ask: "What is the smallest amount of the above problem that we can solve, and still be useful?"

Combining Code Review with Paired Programming

2005-05-24T11:09:00.000-07:00

Combining Code Review with Paired Programming:
An approach by Kevin Klinemeier and Charlie Sheppard

The first rule of the Code Review: You don't leave the code review with more work to do.
The second rule of the Code Review: You don't leave the code review with more work to do.
The third rule of the Code Review: If this is your first time, you have to ... uh... listen. We're not that hardcore.

Code reviews can be stressful, frustrating, and/or a waste of time. This approach attempts to avoid at lot of that by being more like a pair programming session (with keyboard and projector) than a review of a bunch of printed-out code. Take a laptop with your favorite IDE and the latest version of the codebase. Sit down with a group of 3-5developers and pick a few classes to review.

As you review a piece of code, rather than noting suggestions as tasks for later (see rule #1), actually make those changes to the codebase. If they're too large to be made in a single code review, pare the change down to what you *can* do, and do that. At the end, check in your changes and be done with it.

This approach tends to be much more interesting for the participants because there's more interaction, and is more productive because you can see your changes made as you suggest them.

It is important to be serious about the no-extra work rule. This keeps your developers from thinking, "Ugh, we have to go to an hour-long meeting from which I'll gain two more tasks to do this week. Screw that, I don't have time." Sacrifice your changes before you sacrifice the no-extra work clause. Adding extra work in the review causes the review to be skipped in 'crunch time', and ultimately lost along the wayside.

In general, when you start or amend your code review process, let your developers know that they should expect that they *will* find changes. Nobody is capable of keeping all the possible considerations in mind while they're writing software. That's why we do code reviews, and why paired programming is so powerful. Also, even if your software is very, very well written, you don't put several developers in a room and ask, "Hey, what do you think of this piece of code?" and get "No changes" as a result. It just doesn't happen.

The last thing, and this is obvious, but be polite. There may very well be a reason the code is the way it is, or even if there isn't (it really is that bad), it's likely the author and the rest of the team already knows better. Laugh at yourselves from time to time, and overall stay positive. Talk more about what can be fixed, rather than problems left behind.

A Better Mock Objects explanation

2005-05-24T10:56:00.000-07:00

So, despite my February posts to the contrary, last week I finally understood what Mock Objects are. Or more directly, I finally understood what they aren't. Martin Fowler's article entitled Mocks Aren't Stubs really laid it out well. Stubs are used for state-based testing. Mocks are used for interaction-based testing. Using a Mock when what you want is a Stub generally results in the interaction-testing features getting "in your way". This is the case for the www.mockobjects.com mock implementation of the various HTTPxxx interfaces. They add a lot of useful methods for testing interaction, but when all I want is to set attributes, they're "in the way".

Martin Fowler's Article:

http://www.martinfowler.com/articles/mocksArentStubs.html

Mock Objects explanation

2005-02-11T10:00:00.000-08:00

I wrote what I think was a very good explanation of the Mock Objects approach on the junit mailing list today, so I've copied it below.

One thing I found interesting was the way I ended the message. I said, "I think Mock Objects are fun".

What a curious thing to find fun. It's true, though. Writing Mock Objects gives me a special kind of gee-whiz satisfaction that I can't exactly explain. It may have something to do with the fact that writing Mock Objects frequently involves little "tricks" like scoping changes or subclassing and overriding major functionality. In normal code, I'd consider these tricks to be an abherration and a threat to readability and maintainability. For some reason, they're acceptable to me in Mock Objects.

I wonder now if the Mock Objects I've written are horrible monstrosities full of hacks and completely unusuable to those who come after me. I hope not, and in general I don't think so. If there's a readability issue I'm worried about it's when I make a mock object than needs to implement just one method out of an interface, and I let Eclipse just code-generate the rest of the class. Sure, I move the implemented methods to the top, but it isn't exactly clear.

This seems to raise the question, though: If my very-clever Mock Objects are maintainable, then why do I hate and avoid this kind of work in my regular projects? Is it a question of scale, perhaps? I could (but don't) declare most of my Mock Object implementations as final, nothing subclasses them. Is it that there is more subclassing going on in my actual project code, and hence more need to keep things simple? I have my doubts about that as well.

Perhaps I just need to kill my darlings, but ... they're so cute.

-Kevin

The original text:

Often, many of the inputs and outputs of your system are its interaction with other classes. Those classes frequently have states or take actions that are difficult to test (sniffing packets, throwing exceptions).

In order to avoid this problem, you use a class that appears to your unit under test as though it is the tool it usually calls, but under the covers you've stripped out its functionality and replaced it with something you can test with.

Let me assume that in your example, you pass in some kind of network-access object in your constructor, which is then used by various methods. You need to test what your code does when that network object reports that it cannot contact any network at all. This is a very difficult situation to simulate with the actual code.

You create (or if you're lucky, download) a class that subclasses your network access object. That class may be called "AlwaysFailingMockNetworkAccessObject". It is bone-stupid, and is in actuality not a network access object at all. The only thing it does is fail when its access methods are called.

So in your test, you construct your class with this AlwaysFailingMockNetworkAccessObject, and then make your assertions about your class' behavior.

Another test might use a PlaybackMockNetworkAccessObject (another class I made up). This object might not contact a network at all, but accept in its constructor a set of data to return as though it came from a network. Using this, you can write a set of assertions based on a set of data.

One common first reaction to the Mock Objects approach is that "It doesn't *really* test the system" since it doesn't involve some major component. This is when Unit Testers reply, "It tests everything I'm concerned about -- I don't need to test the Network Access implementation, it isn't my problem." You'll also be doing an integration test before you release. This, however, is a unit test, and the Mock Objects approach helps you test just your unit.

Puzzle Pirate Banker

2005-01-31T18:05:00.000-08:00

I wonder if this would be a viable mini-business in Puzzle Pirates:

The "system" (aka the man) charges you a 10% or so fee to transfer your poe between islands. This fee goes up if you want to transfer between islands in different archipelegos.

Could a player or group of players who have significant idle holdings undercut this practice?

The problem is that the poe needs to get there. Either via an able crew, or just general accumulation, let's say for the sake of argument that the poe is at several locations arleady.

One could create a website (that is updated -- the not fun part) that knows how much poe is where. Users can enter the place their poe is and where they want it to go. The system will then tell them how much they can transfer (the lower of the poe onhand at those two destinations), and the fee.

The player would then have to arrange a time to meet with a trusted broker to close the deal.

Building trust is obviously an issue, as the broker cannot trust the customer. Ingame events like auctions and such should be enough to get the ball rolling. False accusations of fraud from dishonest players will be a problem, especially if they occur while the system is getting started.

It may be that the majority of transactions serve to centralize the poe, or worse, decentralize it to where it is scattered and not useful. Talented sailors will then have to be enlisted. Perhaps the sailors could be commissioned, without the need to trust them implicitly. If there exists a general trust in the organiztion, it could itself advertise for "poe delivery", paying a percentage on the income, perhaps at either isle. This percentage would need to be at least 5% lower than the 'transaction rate' charged to customers.

Scale is a problem, as a system of trust would need to be created among the brokers. However, once established, brokers could operate as independant agents to a large degree. They can maintain their own network of poe, post their own bounties for poe deliveries, etc. Indeed, they must maintain their own poe, as no-one can be trusted with the "communal pool". To this end, they will need to make their own deliveries. If agents are competing with each other to make transactions, this will tend to ensure that deliveries are as timely as possible.

Trust could be "ensured" by requiring new agents to provide a "Security Deposit". Agents are then allowed to make transactions up to their security deposit. This provision could be removed for longtime agents. Dishonest players, however, can abuse agents by falsely reporting fraud (certain to happen). This will be indistinguishable from actual fraud.

Agents would be easier to trust if the poe were paid to a central system rather than the agent himself. Perhaps deposits on private sloops or somesuch can be arranged. This would necessitate an investment of purchasing sloops for each new 'source'. Except that doesn't help at all. Dishonest agents can simply falsely report delivery of the poe and collect the replacement payment and their fee.

Is there any way for the agent to "prove" the transaction took place? Screenshots can be faked, chatlogs are laughable. Banking data is private. Perhaps ships can again be helpful? Their transaction logs can show who took the poe and how much, though poe can only be removed by crewmembers. A pirate may only be in one crew at a time, and the customer may not have the ability to add the Agent, nor the inclination to leave his crew to receive his shipment.

These troubles would be acceptable for large amounts (10k+ perhaps), and perhaps the risks are minor enough to dispense with these precautions for smaller amounts.

This entire idea could be expanded to any type of commodity, actually. Storage of anything but poe is difficult, however.

Alpha

2005-01-31T15:51:00.000-08:00

Welcome to my head.