andymatuschak.org: Square Signals

Pixen began in a dorm room. This was ideal for a couple of reasons. First, it was a relaxed atmosphere with lots of distractions. It seems counter-intuitive, but sometimes in a big project, you need distractions to do a good job. Secondly, it meant that we were able to work together in person.

I don’t think the value of working face-to-face with your teammates can be understated. I mean, yes, I’m a big open-source fanatic, and tons of these projects have gone far through years of decentralized work. So I don’t think it’s impossible to accomplish something while physically alone, but I do think it’s a lot more difficult.

Being together meant we could motivate each other, help each other out more readily, and jump directly on another’s computer when something was giving trouble. We could high-five each other when things went well or make Wookie noises with each other when things went badly. And we could take a break to grab pizza or play play Smash Brothers.

I really think it’s an ideal working environment.

Sleep deprivation and code-a-thons

But over a year or two, Joe went to college and Ian’s family moved away. We couldn’t work together in person anymore, so work on the app dropped off almost completely. We got almost nothing done for a huge period of time—it was just hard to get motivated.

A couple summers ago, Joe and Ian came back to Saint Louis to visit, and we ended up doing something completely insane. We call it a code-a-thon. I’m going to preface my description of it here by saying that it is both a really good and a really bad idea.

So on the first night, we outlined a basic list of things we wanted to get done. Then we grabbed dinner and immediately started working. At around 2 or 3, we went to bed. In the morning, we rolled over, grabbed our laptops, and kept working. We basically repeated this schedule non-stop for a week. Every once in a while we’d stop for a quick game or something. And I guess we’d eat every once in a while.

Three heavily-motivated programmers working sixteen hours a day can accomplish quite a lot, even if it’s only a week. Every time we did this, we’d have a few hundred SVN commits and about 30,000 new lines of code. Gobs of new features would be added, and bugs would be fixed left and right. On top of the productivity, these weeks are also ridiculously fun, even if I’d be totally exhausted for the week afterwards.

But it’s not all good. See, as absurd as it sounds, the average programmer writes only 6,200 lines of code a year. While this is a totally pathetic number and only really applies to unmotivated corporate programmers who have been cheerfully de-souled, the three of us writing 10,000 lines each in a week is indicative of something.

That something is really crappy code. And even when the code wasn’t awful, we were adding way too much way too quickly. So two of us couldn’t keep up with what the other was writing, which would lead to duplication, confusion, and tangles.

This leads me to to the first big principle I learned from this whole thing.

Don’t write bad code!

Don’t write bad code. I do it all the time. You do it. Even those guys who write books on how to write good code do it sometimes. Generally, we do it to save time or because we’re under deadlines. Or maybe just because we’re lazy and don’t feel like fixing something or doing it properly.

It’s all about balancing short-term versus long-term consequences, though. Yes, in the short term, you’ll get more done, but in the long term the code will be totally unmaintainable. You’ll have to rewrite vast tracts of code. It’ll get progressively harder to add new things. And a few years down the line, you’ll feel like you want to just rewrite the whole thing.

It sucks, and it ruins projects. Don’t let it happen to you. It happened to us.

The Golden Rule

The second big principle was really the huge problem with Pixen. Why I think it’s not as good as it could be. The golden rule of software!

Quality over quantity.

I first realized this when reading Panic’s excellent The True Story of Audion:

iTunes was, of course, and I’ll say this now, brilliant. It single-handedly taught us an entirely new philosophy on software design. Do you really need that Preference that 1% of your users will use? Can you find a better way to design that interface than having each function in a separate window? Can you clean this up, even if it means it’s a little less flexible? iTunes blazed the trail for clean, efficient software design for a broad audience, a design philosophy we practice actively today. It was a way to take a complicated digital music collection, and make it easy. Sure, it was limited, but man was it easy.     

Less is more. Especially when it comes to features and interface. The way to make a really amazing application is to have a few good features that are really polished, really unique, and really awesome. Figure out the ways that make your app stand out. What features do you have that no one else has? Emphasize those, make those awesome, and don’t worry about trying to satisfy everyone.

Every feature you want to publicize or emphasize should be polished, polished, polished! Like to the point where all the paint and varnish has come off, and your friends ask you if you could please put down the rag and come out for dinner.

Try the app yourself over and over again. Make sure any given task is as easy and takes as few clicks as possible. Give it to other people who don’t know anything about computers and see if they can figure out how to do things without any kind of help. If they can’t, then you need to simplify things, because users are dumb.

And if something isn’t good enough, if something fails the usability test, then cut it. Seriously. Your users will forgive you someday. The worst thing you can do is to take feature requests too seriously. We were so excited to get requests from people that we would grant them, even if they were things that would basically only appeal to one person.

I’m Done

I hope this was at least somewhat useful to you. I’ve talked about all the mistakes we made, but a lot of it worked pretty well. Pixen’s got a lot of flaws, and it’s definitely not all I hoped it would be, but I’m still proud of it.

Now I need a new app to write.