Friday, April 30, 2010

The leak that wasn't a bug (i.e. one reason programming is hard)

Bugs are a pain, they eat time, destroy quality, and seem to almost always happen at inopportune times. What's even worse is when the bug is in a 3rd party library or somebody else's code.

My application needed to monitor a directory for changes to files. Unfortunately, Java 6 doesn't yet have support for directory monitoring, so I started looking around for different libraries. I found two that were good candidates, JNotify and JPoller but ultimately decided to use JPoller because it was a pure Java implementation and was fairly well documented.

It didn't take long to integrate JPoller into my application. Although it wasn't designed for testability in mind, I expected the tests to go fairly quickly, and they did. Everything looked good. After some refactoring I started to implement my next feature. Something was wrong. My file wasn't picked up. The first and second times I just assumed I placed the files in the wrong directory... but I hadn't.

I started looking through the JPoller source. I learned a few things, made some changes and continued the bug hunt. But, to no avail. Despite the logic looking perfectly sound it wasn't working right all the time. It was a race condition.

As luck would have it, I had a startling insight. What if the timestamps were wrong?

After quite a bit of investigation I discovered the insight was correct. Despite the files having a timestamp in milliseconds, it was only accurate up to one second. This allowed the file to be created at 850 milliseconds after some second and to have a timestamp of 850 milliseconds earlier.

The Law of Leaky Abstractions

I had just been struck by the Law of Leaky Abstractions. On a Windows NTFS file system the resolution was accurate to 100 nanoseconds, but on Linux it was accurate to one second. And Windows FAT filesystems were only accurate to two seconds (for modification time).

Despite the cross-platform nature of Java, I had to know and understand file system specifics in order to hunt down and kill this bug that wasn't a bug. Instead, it was a leak, and one that had to be carefully worked around in order to maintain the cross-platform nature of Java.

Programming is hard. It's never enough to know a single language or a single platform. Sooner or later a leaky abstraction forces you into other realms.

Saturday, April 17, 2010

The faller's wedge & ubiquitous language

I've recently been reading Domain-Driven Design, by Eric Evans. One of the foremost things Evans discusses is ubiquitous language, which he defines as:


A language structured around the domain model and used by all team members to connect all the activities of the team with the software.


Without that shared language, problems ensue. The following story, told by Samuel T. Whitman, illustrates well what may happen without a common shared language:


“The ice storm [that winter] wasn’t generally destructive. True, a few wires came down, and there was a sudden jump in accidents along the highway. … Normally, the big walnut tree could easily have borne the weight that formed on its spreading limbs. It was the iron wedge in its heart that caused the damage.

“The story of the iron wedge began years ago when the white-haired farmer [who now inhabited the property on which the tree stood] was a lad on his father’s homestead. The sawmill had then only recently been moved from the valley, and the settlers were still finding tools and odd pieces of equipment scattered about. …

“On this particular day, [the lad found] a faller’s wedge—wide, flat, and heavy, a foot or more long, and splayed from mighty poundings. [A faller’s wedge, used to help fell a tree, is inserted in a cut made by a saw and then struck with a sledgehammer to widen the cut.] … Because he was already late for dinner, the lad laid the wedge … between the limbs of the young walnut tree his father had planted near the front gate. He would take the wedge to the shed right after dinner, or sometime when he was going that way.

“He truly meant to, but he never did. [The wedge] was there between the limbs, a little tight, when he attained his manhood. It was there, now firmly gripped, when he married and took over his father’s farm. It was half grown over on the day the threshing crew ate dinner under the tree. … Grown in and healed over, the wedge was still in the tree the winter the ice storm came.

“In the chill silence of that wintry night, … one of the three major limbs split away from the trunk and crashed to the ground. This so unbalanced the remainder of the top that it, too, split apart and went down. When the storm was over, not a twig of the once-proud tree remained.

“Early the next morning, the farmer went out to mourn his loss. …

“Then, his eyes caught sight of something in the splintered ruin. ‘The wedge,’ he muttered reproachfully. ‘The wedge I found in the south pasture.’ A glance told him why the tree had fallen. Growing, edge-up in the trunk, the wedge had prevented the limb fibers from knitting together as they should.”


The Communication Schism

A chasm, or at minimum a schism, often exists between domain experts and developers. Domain experts often use terms that are inexact or ambiguous. Developers use terms specific to themselves and that describe implementation details. This leads to fracture in in both communication and the domain model. This fracture happens at all levels of communication. Without a ubiquitous language used by all team members and the domain experts who largely define the software, a gap between understanding and implementation grows.

Domain experts often use terms that are inexact or ambiguous. Developers use terms specific to programmers and describe implementation details. This leads to fracture in in both communication and the domain model. This fracture happens at all levels. Sometimes it may be a small schism and other times it grows into a chasm.

Without a solid base, a ubiquitous language to meld the domain expert's knowledge with implementation, it is as if there's a faller's wedge stuck in our limbs. Our communication avoids certain aspects of the domain, circumvents necessary detail, and ignores relevant issues.

As this happens time and time again, both developers and domain experts become hardened, they don't see the issues nor understand how to resolve the differences. Rather than build up knowledge, it is skirted and worked around.

In Domain-Driven Design, Eric teaches us how to overcome these problems. I highly recommend it.

Thursday, April 8, 2010

Customer Support is about LOVE

Yes, customer support is about love! It's about caring and doing something because you care. Here are some relevant definitions from Dictionary.com:

Love --
1. a profoundly tender, passionate affection for another person
9. affectionate concern for the well-being of others: the love of one's neighbor
10. strong predilection, enthusiasm, or liking for anything: her love of books
11. the object or thing so liked: The theater was her great love

And that's not it, there are other relevant definitions, but the above are sufficient to make my point:

Customer support and business to customer relations should be about love.

I've recently had a few customer support experiences that I'd like to recount:

Pulsar Watches

The battery in my wife's Pulsar watch died years ago. Sometime after taking the battery out to get it replaced I lost the battery. Nothing on the watch helped us identify the correct battery. My wife, as organized as ever, knew exactly where the receipt was and I was able to look up the model number, but no online searches revealed the correct battery, so I e-mailed pulsar customer support.

Even though the watch was over 10 years old, completely out of warranty, and I doubt they had many electronic records about the watch, they e-mailed me back and provided me with the exact battery type.

To be honest, I wouldn't have minded at all if they had said they had no idea where they could find that information, but they answered my question when they could have easily disregarded it. I could say they showed a predilection for their customer referring back to definition 10. Pulsar watches loved their customer enough to go the extra mile.

The Unnamed Tech Company

The Unnamed Tech Company has a great product that many people love. In addition to their main product they have another product that's quite esoteric but that happens to fill an exact need that I have at the time. I e-mailed them, and then I waited... and waited... and waited. Nothing. I decided to e-mail them again, this time at a different e-mail address, explaining my previous e-mail, and clarifying my intention to purchase. And then I waited... and waited.

I did finally receive an e-mail back, but now I'm waiting for a response. Support has been lackluster, perhaps almost dismal. In the spirit of full disclosure they admitted my first e-mail went into junk mail, but still. I'm a potential customer, or could have been an existing customer, and my e-mail was lost. They didn't answer all my questions and still haven't reached a satisfactory conclusion.

Netflix on Proactive Love

Netflix constantly amazes me. Even their company culture is amazing. But, it goes far beyond that. They are passionate about their customers. Yes, that's right. They love their customers, or at least I think so... and I doubt they'd say otherwise.

A few days ago, after having streamed a movie the night before, I received an e-mail asking me how the quality was. I was impressed. Not only were they proactive, but they really wanted to know. And, I'm happy to say that the quality was superb. For a 10-15 year old movie, I can't imagine the picture being any better had it been on Blu-ray.

But... it doesn't stop there. Monday I sent back a DVD which they received early Tuesday morning. Nice and quick. I was impressed. But, it gets better. They then asked me when I mailed it. They actually wanted to know how well their service was doing. Was it taking too long? Would they consider building a distribution center closer to me? I don't know, but I knew they cared. I knew they loved their customer.

Love Your Customer

If you and your business doesn't care about your customers, change jobs, or something. As Gary Vaynerchuk would say, follow your passion. Show your customers you care. Make a difference in their lives. When you do, they'll become your earlyvangelists, your marketers, your best and most devoted customers. And, perhaps most importantly, they'll love you back, and forgive you when you make mistakes.

[Image Courtesy: dolphinsdock on flickr]