Simple, yet polished

I have been thinking a lot about polish lately. How it’s often better to have a simple app that’s really polished than a more complex app that feels clunky.

My son is part of the 10% of the population that is left-handed. He’s also part of the 8% of male population that’s color blind. Imagine how he felt when he saw that the iPhone port of Peggle specifically supports color-blind lefties?

Oh no, not more of the same TDD discussion Tedium.

Every once in a while, otherwise reasonable people get together to argue about TDD with religious zeal. In the most recent flare-up, I’ve been disappointed that on all sides, as nobody is saying anything new.


At the risk of adding yet more noise, I did have a two nuanced thoughts that are at least new to me and I thought I would share them, along with a recent personal anecdote.  If this is obvious or old-hat to you, then I’m sorry.  If you think I’m  too stupid for words and that I’m drinking and/or selling snake-oil enriched kool-aid, I look forward to what will undoubtedly be informed and insightful feedback.

1. s/driven/aware/

The hardcore position of “never write a line of production code without a failing test for it” probably does more harm than good. Different kinds of code require varying degrees of effort (cost) to write and maintaintests for. Different kinds of code give varying degrees of benefit from test automation. Without always realizing it, developers make cost-benefit decisions all the time, and good development organizations empower their developers to act on those decisions.

That said, the cost-benefit decisions developers make must at least be informed decisions. A professional developer who hasn’t taken the time to learn how to use the appropriate test frameworks for their language/environment (jUnit, nUnit, whatever) is just plain negligent in 2009.  Test automation is just one tool in a competent developer’s toolbox, but a critical one.  I wouldn’t trust a carpenter who didn’t know what a hammer was, or a cardiologist who hadn’t bothered to learn about this newfangled angioplasty business.

Test-driven may not be appropriate for every context, but everyone needs to be at least test-aware.

2. s/first/concurrently/

Test-first is a really helpful approach, but it doesn’t work with the way everyone thinks, and mandating that everyone must always think in exactly the same way is the worst sort of micro-management.  The other extreme, writing test automation for a large system after it’s complete, is often prohibitively difficult and (frankly) boring as hell.

My advice is to always at least think about how you would write tests for your code before writing it. That will help keep you from painting yourself into untestable corners. Also, interlacing test writing immediately after you get a small subset of your system done is going to be much easier than testing the whole thing after the fact.  Personally, I move back and forth between writing the tests first and writing the code first. The key for me is that I’m working in short code-test-code-test cycles, using persistent (that is, I don’t throw it away when I’m done) test code as the primary mechanism for executing the code I’m writing as I’m writing it.  I don’t think of the process as being test-first, I think about testing concurrently with coding.

Recent Anecdote

Sure, anecdotes aren’t data, and they can’t prove anything, so take from it what you will

I just finished a pretty big refactoring project (that is a “pure” refactoring, the external interfaces and behavior of the existing stay the same but the underlying implementation was improved) of a system that had some decent test automation. Every time I got an edge case behavior wrong, introduced a side-effect, or removed a necessary side-effect (yuck), a test would go from green to red. This saved me at least a few days of development and testing time, and reduced the chances that I would release bugs to our QA guy (bad) or our production system (even worse).

It takes a good journalist to make software development interesting

Emily (who is best described as the heart of I Can Has Cheezburger) came into my office yesterday and looked around. “KING 5 news is going to be here, so we just want to make sure that there’s nothing offensive up anywhere”

There wasn’t. We used to have a copy of the Hot Chicks With Douchebags book as part of our display library, but that’s missing now. I was displaying my “Wrong-Face Panda” picture, but that’s meant to be disturbing, not offensive. Nonetheless, I tidied up the office a little bit and sat with better-than-normal posture as the news crew visited Ben in his little closet of an office, and then went around, poking their giant camera into different workspaces. They came to my office ,where Ben introduced us as the development team.

The news guy just shrugged and gave a sarcastic “Oh, software development, that’s really interesting” before walking away.

So I yelled back “Yeah, so is local news!”

That’s right, I actually came up with and executed a Winston Churchill-style zinger at the right time, not the day after.   I’m usually not so touchy, but that guy was just being a jerk. Think about it: would you come into some professional’s office and insult what they do?

The truth is, that the story of how we do software development is interesting. Some examples:

Our user activity is massive. We serve six million page views daily. We have a database of over four million funny pictures. A thousand new people register to participate in our community every day. We tally and act on hundreds of thousands of votes every day, in real time.

We’re a small team and we have to generalize and do more with less. We don’t have a dedicated test person, so we make our own robots to test our sites for us. We move quickly (turning around new ideas in days or weeks instead of months or years) yet we have really high stability with fully redundant systems that repair themselves if something goes wrong.  We deploy new code with zero downtime by pulling a server out of service,  upgrading it, and putting it back into service after we’ve tested it.

All of our office infrastructure is virtual. There are no desktop phones or LAN servers. We use Internet-based tools like Skype,  Tokbox, Google Docs, and ReviewBoard to collaborate. Some key members don’t even work from this office, yet they are just as productive as someone who works right here. Our office is essentially paperless, the only time I’ve ever used an office printer was for personal use (sorry).

We have created a public API which opens up our systems to any developer who wants to contribute or use our content in their programs. You can take pictures on your iPhone, drop text on them, and send them directly to us using a program that some guy made for free just because he wanted to.  We’re plugged in to the emergent web ecosystem; we integrate with WordPress and Twitter and YouTube and Digg and Facebook. We’re working on all sorts of new stuff that will be really cool.

We’re living and working in the bright and shiny future of tomorrow, as a profitable Web 2.0 company.   The truth is, I don’t really care if some old-media guy and his ever-shrinking audience doesn’t get it.

Script Frenzy 2009 – Writing a Screenplay in 30 days. Here I go.

When I was about to start my first attempt at National Novel Writing Month, a friend of mine said “Martin, you’ll have no trouble with this, you have a skill for telling things as they are

“Thanks, but I’m writing fiction”

“Oh.Never mind, then.”

In the same spirit (and organized by the same lunatics) as National Novel Writing Month (every November) is ScriptFrenzy (every April). I participated in ScriptFrenzy in its premiere year and managed to finish a flawed but readable script for a feature film about an insecure superhero investigating a crime involving his former partner who was framed for taking performance enhancing drugs.

This year’s script is for a two-hour pilot for a television drama. It’s set a few years after a mysterious natural disaster which has destroyed every large city on Earth. My characters are (so far) a former Ju-Jitsu instructor turned fisherman turned militia leader, an agrarian bible scholar turned underground spy, a cokehead airline pilot with political ambitions, a fugitive former CIA agent taking refuge with old mafia connections, a shameless disaster profiteer, a teenage girl trying to break away from the UFO cult her family is in, a HAM radio geek turned talk radio superstar, and a cute young journalist who rides a Vespa (her character needs some more depth, obviously).

I’m working under this basic formula, but it’s changing from moment to moment:

(Left Behind – Kirk Cameron/evangelical message) + (Battlestar Galactica – Cylons/Space Travel) + (The Sopranos – pop psychology)  + ( World War Z – Zombies ) + (X Files – creepy sideshow episodes/aliens)

The best thing about writing a TV pilot instead of a feature film is that you don’t have any pressure to wrap things up. I’m going to just open up a whole bunch of messy loose ends and leave them there with an outlandish cliffhanger ending. It seems to work for J.J. Abrams.

After the first two days, I’m off to an OK start. Last night I literally fell asleep at the keyboard and typed an entire sentence with my eyes closed. Upon further inspection, I had to throw it out as it had no vowels in it. Tonight was better and I managed to get up to 8 pages (target is 100 pages in 30 days, so I’m a page or so ahead of schedule).

A big part of making a writing project like this succeed is the visible public commitment to meeting the deadline. This is the same reason that many teams get benefit from doing daily stand-up meetings, is that coders can stay focused more easily when they commit to action in front of their peers. By telling everyone that I’m doing this, it’s a lot harder to just give up silently and go back to watching Hulu or playing iPhone games.

Wish me luck.

One of the Coolest Things I’ve seen in a while.

Construx to Offer Free Training to Laid-Off Software Developers

This is a total win-win.

Laid off people get some training to keep themselves sharp when they’re not working, and a recent line item to put on their resume.

Construx gets some additional brand awareness/mind share/word of mouth (just think of all of those resumes going out to their target market). They also get the advantage of filling up their classes at a hard time to do so. Trainings like theirs (I’ve been to many) work better with a critical mass of participants.

Here’s hoping other companies will do creative things like this.

It’s Like Working in a Record Store

Here I am, posting for the first time in a very long time, which is kind of a shame as I had been meeting my at-least-one-post-a-week schedule for a while. Here’s the story:

A few months ago, I decided that it might be time for me to change jobs. While I had learned a lot working with both my client and my staffing agency, I felt there really wasn’t anything exciting on the horizon. The project I was working on was described as “wholly unremarkable” by Gizmodo, which I thought was about right.

The biggest issue for me, however, was the structure of the development organization. The people who created ideas and the people who implemented ideas were never the same people, by design. And while there was a possible opportunity for me to move into doing more idea creation and less implementation, I don’t want to go post-technical yet.  I like writing code.

I did enjoy playing the role of full-on code monkey and improving my chops at the bottom of things. I’m a much better hands on-coder now than I was.  Not only do I write better code than I used to, I’m better at talking about code. I did a handful of presentations on the whole tdd/refactoring/code qualities/design patterns universe. Trust me: nothing helps you understand where your weaknesses are better than having a room full of developers asking you tough questions about a new concept. I also got to do SDET stuff for a while, which is something that all developers should do from time to time (I have more to say on that concept in a later post).

Anyway, I cautiously started looking for something new. I put the RSS feed of a Craigslist job search into my Google Reader and waited. I only responded to a small handful of listings that seemed like interesting companies. One company could have been really good for me, but they were planning on moving from Fremont to East Bellevue. While I don’t want to come across as the latte-drinking Seattle snob that I probably am, I’ve really come to enjoy not driving to work and I’m seriously not ready to ride my bike from Ballard to Bellevue.

And then, one day, this comes up in my RSS reader:

Be a .NET Developer for Cheezburger ( (Lower Queen Anne, Seattle)
Help us make the intarwebs a better tube for millions as we develop some amazing tools and features (we’re more than just a blog under this fur!).

I’m not even huge lolcat fan, but I have realized that I’m an internet culture person. I read in an article about Internet Trolls (which I’m not, just to be clear) that their favorite video game is Portal and their favorite TV show is House. I thought “Oh no! That’s me!”. Besides the Portal/House connection, I blog (of course), have a Flickr stream, I subscribe to few dozen RSS feeds, I listen to streaming radio on my chumby. I listen to podcasts on my iphone. I use facebook/linkedin/twitter to keep in touch with people. Heck, even the times that I specifically unplug from the network (NaNoWriMo and ScriptFrenzy) are essentially internet culture things that happen largely asynchronously.

So, after three weeks of working to make the intarwebs a better tube, what’s life like at the Cheezburger factory? It’s like working in a record store, only for internet geeks instead of music geeks. There’s still a lot of real work that needs to be done, but it all essentially centers around helping people do a better job of wasting time online. Or, if you want to take more uplifting view on it: we make a few hundred thousand people happy for a few minutes every day.

Besides just being in a position to both create ideas and implement ideas, the favorite part of my job is when we get together for Thai food on Thursdays and just talk. We talk about our favorite webcomics (in what would come as a surprise to nobody, Garfield minus Garfield and XCKD are both universally loved). We wonder aloud what kind of people will come to the Fail blog meetup. Someone noticed the “NEDM” inscription on a picture of Happy Cat. It turns out that “NEDM” is an acryonym from the YTMND community which stands for “Not Even Doom Music”, which is to say that something is so horrible that not even the soundtrack from Doom can redeem it.  Yeah, Internet geeks, srsly.

One specifically cool thing about working here is that all of the infrastructure is on the cloud. There’s esesentially no LAN. We use gmail and google docs instead of exchange/office. We use the Mercurial distributed source control system. We use ReviewBoard for code reviews online. The result? I can work just about as well from home or from a coffee shop or from Europe (as one of our developers does) as I can from the office.

And now that things have settled down, I’m renewing my pledge to keep a blog posting schedule and try to write at least one thing worth reading every week.  Wish me luck.

Alternative to AlternatingItemTemplate Redundancy in ASP.NET

One of the facets of good coding practices that almost everyone seems to agree on is that redundancy in code, usually via copy and paste, is a dangerous thing.

I saw a great example of this in some ASP.NET code I was working with recently. A tester had reported that some of the items in a display were being truncated inappropriately, while others weren’t being truncated at all. I looked at the screen and could immediately tell what was wrong. Every other row in the table was truncated. It corresponded perfectly with the ledger-paper-style alternating background colors.

Looking at the code, I saw the following things (simplified):

<asp:Repeater id="repeater" runat="server">
<tr bgcolor="#FFFFFF"><td><%# DataBinder.Eval(Container.DataItem, "Title")%></td></tr> </ItemTemplate>
<tr bgcolor="#CCCCCC"><td><%# DataBinder.Eval(Container.DataItem, "TruncatedTitle")%></td></tr>

The vast majority of the code in AlternatingItemTemplate has the same intention as the code in ItemTemplate. Whenever you have duplicated code (or near-duplicated code) you will eventually forget to update one of the two things that need to be updated in parallel. Hence the bug.

An alternative, would be to not have the duplicated/duplication-heavy AlternatingItemTemplate, but instead, call a method to get the row color, like this:

<tr bgcolor="<% = GetCurrentRowColor()%>">
<td><%# DataBinder.Eval(Container.DataItem, "TruncatedTitle")%></td></tr></ItemTemplate>

In the code behind (or even someplace more generalized, if you are going to use this layout more than once, of course), you could have this simple logic:

private const string initialRowColor = "#FFFFFF";
private const string alternatingRowColor = "#CCCCCC";
private string lastRowColor = initialRowColor;
public string GetCurrentRowColor()
 if(lastRowColor == initialRowColor)
lastRowColor = alternatingRowColor;
return alternatingRowColor;
lastRowColor = initialRowColor;
return initialRowColor;

One Courtesy Note: in the off-chance that my comrade who introduced this problem is reading this, I don’t mean to single you out or pick on you. It’s the sort of mistake that I’ve made a billion times myself, and wanted to capture what I felt was a reasonable solution to the AlternatingItemTemplate redundancy problem.

Also, in case any ASP.NET gurus are out there, I generally don’t like to use the DataBinder.Eval syntax, this is a simplified example, remember?

Kind of Chunderwhelmed

For my birthday (I’m now 100000 in binary) my lovely wife got me a Chumby to place in the kitchen. Specifically, it was to replace the low-quality radio that I had in there. I wanted to be able to listen to internet radio (mostly the KUOW stream) as well as view various photos from flickr.

It does both of the things that I want it to, but neither in the way I actually want.

Internet Radio

Turning on the radio consists of (1) squeeze to bring up control panel. (2) touch  “Music” button, (3)touch to scroll down to “My Streams”, (4)touch to select my favorite station. (5)touch play. Optionally, if I want to get back to the channel/widget display, I have to (6) touch “done”, (7) touch “done” again, and finally ( 8 ) touch “hide control panel”. 

Yes, that’s 1 “squeeze” and 7 touches to turn on the radio and get back to where I was. Sometimes I want to do this with wet and/or soapy hands. 

Flickr Photos

Flickr has a cool feature where you can get the RSS feed of just about any collection of photographs. You can see the photos your contacts have posted, photos uploaded to a particular group, photos tagged with particular tags, etc. It’s a very cool system. I had assumed that I could just point the chumby at a flickr RSS feed for some of my favorite groups and always get a chance to see new different things. Unfortunately, the Flickr widget doesn’t do this. Instead, I created a simple “Chumby set” in my account, and I’m using the chumby like a simple digital picture frame, looping through the same small set of pictures. It’s cool, but not what I had in mind.

What does this mean to me as a developer?

As someone who both produces and consumes software, this speaks to the difference between a feature and a use case. “Flickr Support” is a feature, while “As an off-camera lighting geek, I want to view new strobist group photos, because I enjoy getting new ideas” is a use case. “Internet Radio Support” is a feature, “as a news junkie, I would like to switch on NPR the moment I enter the kitchen because loading/unloading the dishes is a boring low-stimulation activity” is a use case.

Too often, people are thinking/speaking in terms of features when they should be thinking in terms of use cases. This is not to pick on the good people at Chumby, I think what is more likely is that they were thinking in terms of an entirely different set of use cases than I was. 

To be fair, a lot of things work really well. The chumball game is mesmerizing. The motion sensor works much better than I would have expected. The selection of clock widgets is awesome. My favorite is the death star clock. The sound quality is quite good for such small speakers. Much better than the radio I replaced with it.  I’m still planning  on writing a few chumby widgets of my own, and I plan on getting one to use as a bedside clock-radio. I’m just a little sad that this cute funky toy is so close to what I actually want.