March 2011 Archives

No More Parking Lots

| Comments


When you have meetings, do you make a “parking lot”? A section of the whiteboard where you put unanswerable questions that arise during the meeting? Try making a to-do list instead.

The difference is subtle but important. A parking lot is a list of shoulder-shrugs. It’s codified procrastination. Parking lot items say “We don’t know but surely someone will figure this out later”. You might even write them down, but what are the odds someone will follow up?

Better to define tasks that resolve the questions.

For example, a parking lot item might read

“Do we need to support multiple languages and locales?”

This is bad because it’s not clear how this can be answered, or who’s supposed to do it.

A better to-do would be

“Ask Joel Q if we need to support multiple languages”

Maybe also stick on a post-it identifying who’s going to do it. Now you’ve got a good idea of what’s going to happen next and solve the mystery.

This applies to lots of other items, too. Ever make a list of “Areas for Improvement”? Instead nebulous problem statements like “Too many bugs”, use actionable to-do’s like “Ensure all test cases pass in the test environment before moving on to the next feature”.

[image courtesy sortofbreakit, some rights reserved]

I recently needed to create some test Facebook users, but ran into a problem when I needed to get my application’s access token. So I ended up searching a bit and experimenting, and it’s simple. Turns out all you need is your application id and secret, which is right there on your application profile page (if your the developer for it). Then you just hit the oauth/authorize endpoint of the graph API, and you get back the access token:

curl "

When You Need An Application Access Token

You need to use a Facebook application access token when you have a process that acts on behalf of the application, rather than on behalf of a particular user. This happens when you access your Facebook Insights data for your app via the graph, and also when you want to create test Facebook users for your app.

Sadly, the documentation for this is buried in the authentication guide for the Facebook graph API.

Are Queues Un-Monitorable?

| Comments

In his post on monitoring Ted Dziuba mentions that queues are a crutch that cannot be effectively monitored, and that you’re better off doing synchronous, load-balanced work.

End to end, how do you check that this system is OK? The logical entry point for a monitor is the producer, send a job through the system and check that it gets processed by a consumer, but the asynchronous queue makes that determination a judgment call. What if it takes a minute? What if it takes an hour? Is the system still OK if the time from job production to job completion is a day?

I guess I’d like to think about this a a bit more, since it resonates with my “You should think about testability when designing” senses.

Of course, I’m no queue or synchronized consumer expert, so I’m all ears on opinions and experiences

Monitoring Theory - [Ted Dziuba]


As developers and product owners, we often confuse quality and class.

“We need a quick and dirty version to try this all out”. This phrase is often interpreted as “Build a quick, crappy solution. Commit as many sins as you like. Just get me my features by Monday”.

As developers, we need to dispel the myth that sacrificing quality is a good method for getting quicker results. We should instead stress that if you want something fast, perhaps a solution of a different class is in order.

Quality and Class

A 2011 Ferrari GTO goes 200 miles-per-hour and does zero to sixty in about three seconds. It is awesome. It also costs about $500K. I’m not sure exactly how they’re made, but I’ll bet it’s at the hands of three or four grizzled master machinists in a stone building on a mountainside somewhere in Italy. I’ll bet it takes about 23 months.

The 2011 smart Car Passion Coupe might go 65 mph during strong wind gusts. It runs about $15K and is probably made by robots and extruded from recycled plastic shopping bags.

These vehicles are of two very different classes, but they share identical core features. They transport people, have reliable brakes, meet all safety standards, etc, etc.

My point is that when someone at smart USA said “Let’s make a really cheap car”, they didn’t build a car with a 400hp engine but bad brakes and no crumple zones. That would be sacrificing quality for the sake of class.

Instead they built a high-quality vehicle of a class that stresses economy over brute performance. I’d call it low-class, but that implies it’s bad or something. There’s all kinds of good-but-cheap-and-simple things. Think about that piece of Ikea furniture you bought eight years ago that’s still going strong.

Don’t Sacrifice Quality For the Sake of Class

When we talk about software features, we often ask things like “So do you want this to integrate with OpenID, Facebook Connect, and our own LDAP?” This is like asking “Do you want a Ferrari?” The answer will always be “YES”. Everyone wants a Ferrari.

Sometimes we’ll also say things like “Well, we can get it done fast, but it won’t be maintainable, and the next person who touches it will have a stroke when they see the code”. This is the same as promising a ultra-high speed car with shitty brakes.

What we should be doing is helping people understand that a good way to get quick results is to alter the class of the solution, rather than sacrificing quality.

Keep in mind that it’s OK for someone to want a high-class solution.

When the IPhone was first imagined, Mister Jobs probably declared aloud that it needed to be a game-changing device. He set a high bar for class, and that’s just fine.

Most often, though, we can do with something a bit less involved that the best CRUD system ever made. It probably boils down to having the discipline to always produce a high-quality product, even if its class isn’t top of the line.