Being Careful Is Not a Solution

When someone makes a big mistake, it's tempting to tell him or her to be careful. The developer who deployed buggy code should have been more careful. The support rep who messed up a customer's data should have followed the procedure more carefully. Nobody should have deployed anything during a high traffic time. When problems happen, people get angry and ask, "Why wasn't someone more careful?" And most of the time, some contrite person steps up and says, "I screwed up and should have been more careful."

Being careful is good, but being too careful is bad. An excess of carefulness doesn't atone for systemic flaws. That is, we shouldn't transfer responsibility from an error-prone system to whoever happened to make the most recent error. When I find myself promising to be more careful or telling someone else to be careful, a little voice in my head tells me, "You're ignoring the real problem."

It should be hard for a developer to break significant functionality.

It should be hard for the product to crash.

It should be hard for a customer to make a mistake that requires them to contact support.

It should be easy to know quickly when something is wrong.

All of those aspirations are possible. They just require more hard thought than being careful does. But, through good system design, judicious automation, meaningful alerting, and obsessive iteration, I've found that it is possible to build systems that enable me and my customers to be carefree.

Critical Mass and Aspiration

Some weeks back, Kiril Savino (GameChanger’s CTO) wrote that it’s important for developers to understand and support the aspirations of a code base. Kiril argues that it’s alright for a particular work of code to be messy and imperfect if it’s not inconsistent with the codebase’s aspirations. A hacked together method isn’t great, but it might be acceptable. But it’s a bad idea to directly access the database by circumventing an API designed for that purpose.

I love the concept of code aspiration, but...

Click to read more ...

CSS Code Smells

Writing stable, cross-browser CSS isn't nearly as easy as it should be. Wouldn't it be nice if you could easily avoid some of the most painful CSS pitfalls?

In this post, I'm going to follow the spirit of Martin Fowler's classic code smells and list a small number of CSS-specific smells that cause bugs and limit productivity. I'm limiting my list to writing for modern browsers and IE versions 7 and later. This isn't a definitive or final list, and I plan to add to it as I get feedback and advice.

Click to read more ...

Getting Real About Hacking

The best teams that I've worked on balanced creative hackery (finding creative, innovative ways to solve problems) with craftsmanship (enabling easy extension, testing, reuse, and maintainance). I was intrigued to see Erik McClure dismiss the latter quality, in his Don't be a Codemonkey post:

Good programmers write code that does what its supposed to do in the simplest, most efficient way possible. I don't care if it isn't maintainable, that doesn't make you a bad programmer, it makes you a bad codemonkey.

I disagree. I don't want maintainability-be-damned programmers writing any software that I rely on every day. I also object to labeling a whole class of people, many of whom are very smart, as "codemonkeys". Instead of programmer and codemonkey, I'll use the terms hacker and craftsperson as both are perceived positively.

But Erik brings an important point to mind. Bad things happen when we don't acknowledge that hacking happens and that it's good...

Click to read more ...

The Need for Speed

Your scarcest resource as a lean startup is undoubtably time. There's never enough of it. Sure, you could raise more, but that won't help you against your competitor who seems to have found his market fit while you were charming an investor. No matter what, somehow you're always in the second half, 10 minutes left on the clock, the score still 0:0 and the competition has the ball. I'm constantly reminded of this in my nightly "shit, where did the day go?" freak-out moment.

[...]

Another big driver for speed is making sure to have the right tools and technologies for job at hand. And this has been one of the most exciting rides thus far. We live in a time where new technologies and methodologies spring up constantly and adopting the right ones will give you a clear competitive edge, potentially saving you weeks and months over the span of a year. The question of "does this allow me to build my product faster (without compromising on quality)?" is now my primary evaluator of whether or not to adapt a new technology. Because the less time you waste on technology issues, the more you have to build an outstanding product, which is what this is all about...

Click to read more ...

I'm joining GameChanger!

"I'd like you to be my manager."

Coach Malcolm Lester was promoting me, but, to my 16-year-old self, it was a demotion. Coach Lester was asking me to become the scorekeeper for his lacrosse team. He recognized what was obvious to everyone, including me. I was good at math and I wasn't very good at lacrosse. The best way – the only way – for me to stay in the sport for any length of time was to hang up my cleats and to pick up a clipboard. I said no, but a year later, in my junior year of high school, I finally agreed...

Click to read more ...

Selenium's Sweet Spot: Preventing Catastrophes

I'm proud of the automated tests I built at Sulia. They run in two minutes. They prevent big bugs from reaching production. The false positive rate is about 1%. In over a decade of working on big teams and on small ones, I haven't seen a more effective end-to-end testing regime. It didn't start that way. Nine months ago, our 3-person team had no UI testing at all. Along the way, we've learned some lessons beyond the obvious "use CSS selectors" stuff.

Lesson One: Selenium isn't always the best way to assure quality

The biggest lesson of all is the title of this post. Selenium's sweet spot is preventing catastrophes...

Click to read more ...

Integrating CSS Sprite Creation Into a Build

CSS sprites are a standard technique for improving web performance. Combining a bunch of background images into one big image reduces the number HTTP requests. And that improvement leads to faster pages.

But CSS sprites can be hard to maintain, for instance, when it comes time to add additional images to an existing sprite. I started looking for a sprite-generation tool to integrate into our continous builds. It was harder than I expected to find such a tool. I tried css-spriter, which calculated offsets incorrectly for some images.

Click to read more ...