During those nearly twenty years I’ve been careful to write and speak sentences similar to the one that ends the previous paragraph. Does it standout as carefully written to you? If you’re a software developer you might think it’s a wordy way of just saying a word that I find, frankly, ugly: users.

I think it’s ugly because it totally disconnects the living, breathing, emotional, and real human being sitting in front of your application and turns them into some sort of component in a system. It changes how you design things, how you prioritize features, and how you predict the adoption (or rejection) of both. You need to remember the eccentricities of human behavior, emotions, and rationale (or lack thereof) if you want to make applications for people. It’s ugly because it’s a low resolution word that is used when really high resolution words are required in order to properly think about the problems you’re trying to solve.

Consider the studies done that suggest that people who speak a language that doesn’t have two words for two slightly different colors consider the colors to be identical. For example, in the English language, we have names for the somewhat similar colors magenta, fucsia, and pink – if we didn’t have the word fucsia, there’s a high likelihood that we’d call a swatch of fucsia pink or magenta.

It’s easier to say ‘user’ than it is to say ‘someone who is studying for their GMAT test’, and I’m not always as diligent in avoiding the word as I’d like to be, but I catch myself often because I know there’s a difference between ‘an affluent liberal arts undergrad student’ and ‘returning to school after 20 years of putting off their MBA student’. Both are ‘users’, and both students, but their motivations and expectations are likely different enough to warrant consideration. If I do say ‘user’, it’s not without having first put in the effort to think a user as a person.

The rewards of being able to think clearly about the problems and desires of the people you’re creating solutions for far outweigh the extra bit of cognitive effort required to avoid the easy path.

For the better part of Grockit‘s existence, we’ve been using Pivotal Tracker to manage our agile software development process. Without question, it’s the best organizational tool for agile development teams we’ve seen, and we consider it an essential part of our productivity.

I’m working on a series of blog entries showing how we use it at Grockit for software development, but thought I’d show how you could use Tracker as a personal GTD-style task manager.

Here’s a very fast and light tour of some of the Tracker basics with a bias towards using it as a GTD system. If you’re a software developer and practice or want to practice agile software development, keep an eye out for a series of more extensive tours in the near future.

Pivotal Tracker as a GTD tool from Michael Buffington on Vimeo.

Hi! My name is Kunal and I’m an engineer at Grockit!

At Grockit, we practice eXtreme Programming (XP). No – not that kind of extreme. We are however very serious about testing code. Our process of delivering a clean build to our target environments hinges on a continuous integration (CI) tool called CruiseControl.rb. Confused? Don’t worry – I’ll explain!

After every commit to our Git repository, CruiseControl.rb wakes up from its slumber and starts running all the designated integration tests. For us, that means Ruby, JavaScript, concurrency, and selenium specs. If we’re “green,” meaning that all of our tests passed, then our commit is tagged and worthy of being deployed to a testing environment. If we’re “red,” meaning that a test failed, then the offending Grockiteer has to fix the glitch. CruiseControl.rb has helped us maintain a high level of quality whenever we want to put a feature in front of our users.

CruiseControl.rb works just fine when the build and development team size is small. As Grockit continues to iterate and release, both variables have increased in scope and size:

• Business logic and tests are directly proportional. We write our tests before we write a line of code. When our system complexity increases, the number of tests, and therefore the amount of time it takes to run CruiseControl.rb also increases.
• More engineers = more checkins! In between long CI builds, lots of changesets tend to accumulate in the ether, making it harder to determine the results of your changeset. It’s just not productive to search for needles in haystacks.

To help improve our CI process, I built a tool called CCToaster. CCToaster is an OS X menulet that displays the current status of CruiseControl.rb. Here is what the tool looks like in your status bar:

The icon color denotes the state of CruiseControl – green = success, red = fail, black = unknown. The neatest feature of CCToaster is the ability to track a changeset’s status. Here is what the interface looks like:

And of course, there are preferences:

As you can see, it’s very lightweight and easy to use. If you are interested in downloading the binary or checking out the source code of the project, head on over to the CCToaster Git repository. The application was written in PyObjc and was tested on Leopard (10.5).

Feel free to shoot me an email if you need help setting this tool up for your environment. I hope you enjoy using this application and learning more about the Grockit process.

Farb & Kunal pair posted this on December 24, 2008

Kare Anderson’s blog, Say It Better, featured us in a post about attracting employees.

Massively, a news site that covers the MMO market, gave us a short write up.

SeedWatcher, a blog about early stage start-ups by one of our angel investors, interviewed  me in connection with our latest financing.

At the risk of sounding like a broken record I’ll say it again: SXSW was bigger this year than ever, both in terms of attendees and in the quality of speakers and panels. My SXSW this year started off on the best foot possible. I got to join a cast of awesome people in presenting horribly bad website ideas and it was a total blast. We packed a huge room, made people laugh, and we over the pre-talk dread early on and were able to ride the high of a good talk for the rest of the conference.

And now, while the high is starting to fade, two prominent conclusions are standing out in my memory. I’ll summarize both for now with some deeper blog entries about these conclusions to follow shortly.

First conclusion: games are, for the most part, changing the world in positive ways, but we’re only barely able to wrap our heads around what’s possible.

Second conclusion: there are no users. There are only people. People are intelligent, creative, critical, vocal, quiet, lost, frustrated, reasonable, irrational, tired and excited. Using words like “users”, “mobs”, “teams”, “crowds”, or any other collective sort of word doesn’t help designers build applications that should ultimately be designed to augment and amplify the abilities of a single person.

For a taste of what’s to come, consider my first conclusion and then spend some time at World Without Oil. I can’t say there won’t be a pop quiz later.

Thanks to Kathryn Yu taking a panorama of my fellow presenters while David Hornik mocked all of ideas in typical VC fashion.