This popped up in my feed today: Pixate.
It’s a cross between a motion design tool and an interaction design tool. You should check out the video. It looks excellent, and I can’t wait to give it a try.
We desperately need as many good motion design tools as we can get. The amount of designers I deal with who still think in terms of static screens is staggering.
Sometimes I worry about the level of completion that I’m willing to take before shipping.
On one hand, clients tell me that they love the sense of taste and little details that I bring to a project, but on the other hand I’m always convinced that I’m shipping too early. That’s not just programmer paranoia either. We’ve lost clients before by sending a beta that didn’t measure up. I’m not proud of that, but it’s led us to better ways of testing and of communicating, so I’m not torn up about it either.
Once, six or seven years ago, I had a customer berate me for shipping beta quality software. It was on the release of a 2.0, and I had a 2.0.1 out the next day for him, but I still feel disappointed in myself for letting that get by me. Every other email I got on that release raved about the new features, but the one I really remember was the humiliating one.
Developers are great at ensuring code quality, but often we fall down on product quality. Beta groups, integration testing, PM feedback, all that can only get you so far. Eventually someone tries something you didn’t see, and now you’ve lost a customer.
I’m sure if I got a better business person in here, we’d talk about the cost tradeoff of quality control vs. keeping a customer. But that doesn’t sit well with me. I want to make amazing software, and too often I have to settle on good enough.
How do you measure that software is complete? I feel like we need a role in the organization that’s just ‘software critic’. Someone who doesn’t give a damn about what tradeoffs had to be made and where the budget was set. If we can frustrate that person, then maybe it’s ready to ship.
How do you measure that software is complete?
When you’re a developer, you think of software in terms of features. The app does this, that, and the other thing. It’s pretty easy to talk about what’s in the app, you just use enough bullet points.
Where I run into trouble is writing marketing copy. It’s not just about listing features. Instead it’s about creating a compelling narrative about why my product will make your life so much better that you’ll pay for it.
You have to bring an incredibly different sentiment when writing marketing materials. I wish I was better at it.
Our goal was to finish cleaning the old apartment today. Then tomorrow we could just show up, hand over the keys, and go find brunch.
Of course that didn’t happen. There’s still one more load of stuff to bring over and a couple floors to mop. It’s not much, but it’s the difference between ‘incomplete’ and ‘done’. Luckily, by which I mean intentionally, we set a deadline before the real deadline. It forced us to make better plans, and more importantly, it lets us have a bit of buffer for when plans inevitably fall through.
I’ve worked on lots of things that came in on schedule. I don’t think I’ve ever worked on a project that didn’t use buffer time. Work expand to fill the time available – plus a bit longer while you put the finishing touches down. I think it’s critical to include some extra time in every project.
This morning I picked up a UHaul van for our move to the new apartment. It’s college-moving weekend, so we had a narrow window to use the loading dock. That meant that everything else had to go right. We had plenty of helpers lined up, we had the loading zone at the old apartment booked all morning, and everything was ready to go.
When I got to the UHaul place at 7:05, the manager was already on the phone with someone. He was explaining that they needed to return their truck *now*. Someone had it booked in a couple hours, and the previous booking had failed to return it the night before. I couldn’t hear the other end of the conversation, but it seemed like the person was befuddled that they couldn’t just hang onto the truck until they were done.
The manager explained that they were ruining someone else’s move, and asked when they’d have the truck in. The look on his face said he wasn’t happy with the answer.
He helped me afterwards, but his mind was somewhere else. He was going to have to call the people who booked that truck today and explain that they didn’t have one for them.
I wonder how many times a year he has to make that call.
I ran into an interesting problem today while trying to write some unit tests for an SDK we’re helping to build at work. It involved instantiating a third-party library, then running a few tests to be sure that our delegate code was being called as expected.
The problem is that the third party library contained code to instantiate a UIWebView. At first I was puzzled. That couldn’t be causing a crash. I ended up stripping out the actual test and just putting in a line like this:
UIWebView *wv = [[UIWebView alloc] init];
And an exception was thrown.
After Googling around for a while, I came across a Stack Overflow post discussing the behaviour. It looks like when you’re trying to test UIWebView in a static library, it needs an app target set to run. I created an empty app, set it as the target, and boom, we had a working unit test.
It’s the things like this that make me realize that I’ll never be done learning.
My partner and I were packing up the kitchen appliances this evening and came upon my toaster manual. This little gem is from the troubleshooting guide:
Problem: Bread is jammed.
Possible Cause: The bread may be too thick.
Solution: Most breads, pastries and bagels will fit into the slot, however, occasionally the bread may be too thick. Simply remove from the toaster and slice thinner.
It’s the “simply” that makes it art.
A few minutes ago I got a call from our new apartment manager asking if we wanted to schedule a move-in time for this weekend. This is especially vexing because we did that last week, arranged the truck and friends to help, and set our schedule around it. But it never got written down.
I’ve been on both ends of this situation. Nobody likes getting caught with their pants down because they forgot to write something on a calendar or put the task on their todo list. At the very least, it ends up breaking somebodies expectations, and the first rule of business communication is to be clear about expectations.
Process is about minimizing human error. With some companies, no meeting can be scheduled without going through the scheduling software. I’m not a huge fan of that approach – every layer of process you add removes a bit of versatility.
As a rule, I avoid process unless we’re being consistently hurt by the same stupid mistake. Something should have to impact you multiple times before you put a process in place. Otherwise it’s just following a fallacy where you assume the exceptional case always has to be accounted for. And that’s just human error.
As we pack up the apartment in preparation for a move at the end of the week, I’m struck by how it’s increasingly looking like a student’s apartment. We’re giving away some furniture, so in the last couple days I’ve seen my dining room table, my bookshelves, and my spare bed go away.
I’ve been clearing out closets, so my living room is crowded with bicycles and sports gear. My TV is balanced on an endtable, since we gave away the stand that supported it. Everything looks a little rawer and more exposed. The only things escaping the boxes are essential right up until the day of the move.
It only gets more disorganized from here. It’s like we’re getting all the entropy that was spread around, squeezing it out of almost everything so my things fit in boxes, and that’s what’s left lying around.