“Databases are for Pussies”

— from Myles Byrne.

Phil Karlton is quoted as saying: 'There are only two hard things in Computer Science: cache invalidation and naming things.' You'd think that because I'm a programmer studying Computer Science (I love the capitals!), that would make me a Computer Scientist. That misconception only occurred to me recently. 99% of programmers out there aren't Computer Scientists. Therefore, I'd propose the two hardest things in programming are not cache invalidation and naming, but business and interfaces. I'm not going to talk about why I think business is so hard for programmers now: that point, I think, should be fairly obvious. I'm adamant, though, that interfaces are the other most important thing for programmers.

The days where we can sit in dark room with a full-sized console hacking away, are gone. The web has now coupled design to development and you would be foolish to ignore that. You can't make any technology decisions without considering how they would affect the user interface. Should I use AJAX for this? Should I make that query? These decisions need to be driven by the experience you want to create for your users, not what is easiest for you or what is the most “comp-sciency” solution. I believe that people would find a beautifully crafted site with great content and a 5s load-time more becoming than 0.2s site in Comic Sans (and so does Patrick Lynch). We naturally think about things like processes and data but rarely copy-writing and layouts. I admit, I find these skills hard to practice and I'm not getting taught them as part of a Computer Science education. However, the number of talented people who are taking up design as an essential skill only enforces a trend towards Vitruvian programmers.

Starting new projects always sucks me into making tech decisions. I recently got excited about a new project. 'I can't wait to get started, I can use CouchDB! It's going to be so awesome!!!' Ok Chris, calm the fuck down and take your finger off SHIFT-1. CouchDB won't make any difference to whether users will like like your app or use it correctly. CouchDB is shiny and you can't let yourself get distracted by shiny things until you know what is actually going to be in your site. I know if I start building something using CouchDB I'll create my own ORM (what can I say, I'm excitable), which will be good but wont quite fit the site, so I'll end up making decisions based on what is easiest to do with my ORM. I should be making decisions based on what is best for my users and those decisions can't be influenced by technology. In a recent talk about Google Wave, Cameron Adams said something along the lines of 'create perfection, then work backwards from there.' He was referring to user adoption of UI but the same concept applies to technology limiting UI.

Beginning a project with the UI (or "rapid prototyping") is also an enormous business advantage. Most shops can get simple mockups deployed fairly quickly. Create an index.html and hit upload. However ask a Java shop to do more than static HTML mocks. Ask them to serve some semi-dynamic JSON which you need to show off a feature. Big stumbling block because now they need to worry about more than just hitting "upload". 'Ok, talk to the sysadmin, fire up a new project in Eclipse, get Ant running and, oh yeah, do some coding.' The Agile Nazis could have a holocaust with that one. There should never be an acquisition of power during the life-span of a project, only only the dissolution of self-imposed constraints.

Tyrone

That is where Tyrone comes in. Tyrone is a code generator and library designed to help you get up and running designing UI mockups as quickly as possible. It's meant to motivate you to start your projects designing interactions rather than pushing code and making ORMs. Also, by using Sinatra, Tyrone can quickly help you create stuff like semi-dynamic JSON and then move onto a larger Rails project when it's needed. Just use the tyrone command to get started:

$ gem install tyrone
$ mkdir my-new-app && cd my-new-app
$ tyrone init

It works just like the rails command. This creates a new project with a skeleton Sinatra app and a few Javascript files. All bundled up nicely for instant deployment to Heroku. You can then start by adding files to the mockups directory. Easy peasy.

Tyrone is opinionated. It comes with:

A nice index page (for easy access)
jQuery (as it is faster to code simple things than Prototype)
Tim Lucas' states.js (lovely inline prototyping) and Myles Byrne's grid.js (lovely grid overlays)
An empty features directory (writing stories is a great way to define your app early)
A HTML 5 reset stylesheet

You will use HTML 5 for your app. It's the way of the future and also includes nice input attributes (see autofocus and placeholder) which means you have to code less JS. If you absolutely can't use it, backporting should be fairly trivial.

Tyrone is only built for initial prototyping: you should eventually switch to a fully fledged Rails app. That process shouldn't be too difficult as you now have user stories and HAML views all ready to go. The index page purposely limits the usefulness of Tyrone: when you want a custom index page, it's a sign you should move to Rails. I worked on a project recently where we started with Sinatra for prototyping and had intended to move to Rails. However, when time started to slip away it seemed like too much hassle to switch. We ended up replicating migrations, form helpers and even had a "controllers" directory. A lot more code was written than was needed (the app, however, was still awesome because we carefully prototyped the UI before implementing it).

Oh, and the name comes from Tyrone's Dog Babysitting Service. You can be sure that my boy Tyrone loves your UIs more than he loves dogs.

So, something to try on your next project: design your interface first. Focus on copy-writing. Focus on cutting features. Do 10 different variations of the same thing. Figure out what exactly your user wants, rather than focusing on that interesting, shiny technology. It'll be hard at first, but remember: “databases are for pussies”.