Posted on

Must Love Chaos and Compromise

Progress continues to lurch forward in fits and starts as we settle on the personnel configuration to lead us to launch. Having watched a handful of similar revelations occur to many of our previous team members, it has dawned on me that the same factors that make Bonanzle so exhilarating for me are the factors that cause others to turn tail and head for the highway. My conclusion is that, until you’ve experienced the atmosphere before, it is easy to over- or under- estimate how difficult it is to be a part of creating something big from scratch. As usual, Paul Graham has insightful observations on the topic, but reading his poetic account of “hard work” makes it sound more romantic than I think it is. For my time, and the time of our future potential applicants, I think it is vital to accurately describe the most important differences between the startup and non-startup company.

I don’t think that work at a startup is most accurately described as “harder” than work at a large company. One of the “hardest” jobs I ever had was keeping my brain busy while I did nothing for 8 hours a day as a web programmer at the University Bookstore. A better point of comparison between small and large company is the degree of chaos and compromise you experience on a daily basis.

Specifically, these here are my five biggest contrasts that I think startle people who haven’t been immersed in a startup before:

1. The roadmap is drawn as you go. Well, technically, the roadmap is drawn at the beginning, but the more time gets spent drawing that original roadmap, the more time was wasted when that everything-you-know-is-wrong moment happens. Startups are about doing, not speculating.
2. Despite the best intentions, things will be broken. Sometimes with no easy solutions. And it will take creativity to work around it.
3. You are beholden to deadlines. No matter what excellent new service pack is available; no matter what important features from the next milestone one would rather work on. Of course, sometimes that excellent service pack absolutely does need to be installed, so you have to figure out the relative degree of necessity.
4. You are beholden to deadlines. Items only get checked off the schedule if each and every team member is 100% productive with their time. Working at Microsoft it might well be weeks before somebody notices you’ve been spinning your wheels over a certain problem. At a startup, spinning your wheels for 3 days will show up on the schedule.
5. You are your manager. And you are your everything else. Even in a company that attempts to create specialized roles, there usually isn’t time to send an email to the manager to get a task clarified, then get ahold of your web designer to create HTML, before finally working on the original bug that had been assigned to you. Instead, each person must often use their confidence (and common sense) to guide them to a sensible solution when a task has not been well-defined (see also item #1).

Look down the list, and there it is: compromise, chaos, compromise, chaos, chaos. Is it intrinsically harder to deal with chaos and compromise than a lack thereof? I doubt it. But it does take a special personality to have the confidence, patience, and foresight to see how the decisions they make on an everyday basis might seem like chaos, but when the dust settles, suddenly something amazing stands where moments ago there was nothing.

That is the payoff that awaits those with the grit to make something big happen.

Posted on

Oh my gosh that’s kind of evil

Who would have thought? Some 5 years after Google emerged in the public consciousness, and they have done their first kind-of-evil thing. When I logged into my Gmail this morning, there was a big, red stripe across the top of my Gmail account warning me that if I didn’t disable Firebug (web debugging software used by 99% of all web developers, 100% of all web developers in their right mind), than there could be severe performance penalties while I used Gmail.

I will admit that I was pretty disappointed that Google chose to try to make users change their habits, rather than taking the extra time (and yes, cost) to get Gmail to work with a tool so common amongst web developers. But at the same time, it made me re-realize just how seldom Google chooses to take the low road like this. In the pre-Google days, it was routine for applications to make me reboot my computer to install them. Or for applications to not include an uninstaller. And include spyware. And pester me with waits to use them if I didn’t pay.

Of course, many applications still do these things, and I don’t think that Google alone has turned the tide away from these annoying practices, but it has certainly risen public awareness that “don’t be evil” is a viable business strategy that can create both adoring users and a profitable bottom line. Katy recently pointed out that it should only be a matter of time until Starbucks’ insistence on charging users $6.00/hour to use the Internet could come back to hurt them. I hope she’s right. There is no need for these kinds of business practices, when righteous users now know to stand up to them.

Posted on

Manually Set Rails Migration Version

Here’s another piece of info that wasn’t easy to discover using the Google query I expected. If you should ever find yourself needing to explicitly set the migration version that Rails thinks you are at, perform the following steps:

1. Open your Database (using MySQL, this should be something like “mysql -h localhost -u root -p”, followed by “use [database name];” in the MySQL console)

2. Run “Update schema_info SET version=[version number];”

And you’re done!

Posted on

All Coming Together

You can look it up on www.williambharding.com — there are few things that I love more than seeing a plan hatch, and that’s just what I’m seeing as this site makes some big steps toward being the most usable site of its kind for its users. We began our first round of seeking seed investment this week, and so far, so great. People seem to quickly comprehend how this will be a big step forward in shopping, and the fact that I have a team that personifies awesome certainly makes for an easier sale.

hedgehog.jpgOnce we finish acquiring our seed funding, things get really fun. The old adage of “time is money” inverts to state “money is time,” and my hope with seeking our first group of investors is that the money we can obtain will buy us many months of time compared to the means that I’ve used to get the site to where it is now. I’ve been fortunate to get significant discounts on basically everything we’ve purchased so far (web design about half price, programming costs ridiculously low for the quality) by getting people excited to be part of the idea, but goodness, having a bit of capital to work with is going to open a lot of exciting new doors.

There’s still a hell of a lot to do, but if the team matters as much as the product, we’re golden.

Posted on

Automatically Reload Modules On Change In Rails 2.0.x

This problem had me stumped longer than any other single problem I’ve run into so far, and no group or search query I could come up with was able to help me; ultimately I had to figure this out by diving into the actual Rails source code and digging until I found the right concoction. Perhaps this solution was not more findable because we’re running edge Rails? All data I could find on the forums seemed to say that Rails 1.2 did not have these sorts of problems, but I can neither accept nor refute that.

The problem I’d been having was that I had created a Rails Module in a file that was in a subdirectory of my /lib directory. The point of this Module was to allow me to share some methods between a select few Rails controllers without putting the methods into the global Application.rb (which seems sloppy to me…methods should only be available in the scope they’re needed says I). Actually, figuring out that I could create a Module in the lib directory to DRY up my controllers was also surprisingly difficult to find Google information on… you’d think people would object to putting stuff in Application.rb more often. Anyway, I digress.

This Module in the lib subdirectory had one annoying problem: when I made changes to it, I had to stop and re-start my Rails server for those changes to take effect. That got old fast. After the aforementioned digging, here were the TWO LINES OF CODE that took me way too many hours to figure out.

In Environment.rb: Add the path for the lib subdirectory where my module was stored, e.g.

config.load_paths += %W( #{RAILS_ROOT}/lib/item_setup )

There is a commented line in environment that has an example of the syntax for this.

In Development.rb: Add the name of my Module to the explicitly_unloadable_constants list, e.g.,

Dependencies.explicitly_unloadable_constants = 'NameOfMyModule'

And voila! It works. If you have other modules you want to automatically reload, use the << operator to add them to the explicitly_unloadable_constants array, e.g.,

Dependencies.explicitly_unloadable_constants << 'NameOfAnotherModule'

The other possible problem that I read about on the forums that didn’t come about for me was that if my lib directory had somehow gotten listed in Dependencies.load_once_paths, then it would not reload on being changed. You can Google around to figure out how to fix that (hint: delete your directory from the load_once_paths array), but it probably won’t be an issue.

Posted on

Inflection Point

2-3 weeks. That is apparently about how long it takes to reach the productivity inflection point with AJAX/Ruby on Rails/Javascript. After spending many a day stumped on various problems that seemed like they ought to be “minor,” I found myself today refactoring our most complex controller from top to bottom, fixing a couple bugs, and having the damn thing improbably work. Cool. Maybe there’s something to this language.

In seriousness, most all of this week’s interviewees have expressed considerable curiosity in how RoR differs from the other scripting languages, and why we chose it. I don’t know that I’m entirely qualified to compare it to “other languages” since my experience in both ASP and PHP has been purely C-like procedural goop written before I had OOP experience. Though that does hint at the first difference I can confidently draw between the three languages: whereas other languages tempt you at every turn to write ugly code, RoR takes MVC architecture and unit testing into its own hands to minimize the initial time penalty for writing clean code.

The database model conventions and migrations took some getting used to, but I am growing to appreciate them more as well. There is sense and utility in having a memory version of your class that mirrors the database version of the class. And it’s convenient to be able to quickly and easily commit a class instance in memory into its database counterpart. I have never even attempted to do that in another language, but I know that last time I used ASP it wouldn’t have been easy, and I imagine that is probably still the case with them.

I’m also very fond of the gem packaging system that is used to add plugins to RoR. Even with lowly DOS, installing a new plugin for one’s site is often as easy as “gem install pluginname.”

These are amongst the more superficial differences between the languages, but some of the easier ones to describe. It feels a little bit jurassic to be debugging with a console again after having used Visual Studio debugging, but it works and you get used to it. An applicant who I asked about PHP debugging wasn’t even sure if/what PHP debuggers existed, so I can’t imagine that the situation is radically better for PHP. Though I doubt it’s worse.

So, on balance, I’m giving a thumbs up to the advantages of RoR over the other languages we could have chosen. And this is after using it but a couple weeks. I’m very much looking forward to seeing what I can get done with it once I truly learn to start think like a Ruby programmer.

Posted on

Thousands of Pieces

Apologies, blog.

Clearly, there’s something of an inverse relationship working between how exciting my life and blog are at a given time.

Because while days pass without an entry on here, we are still full tilt in developing a working prototype of Bonanzle. bonanzlelogo.pngEvery day a new piece falls in place, but with what seems like thousands of pieces to assemble, a fully functioning and tested commerce site isn’t something that pops up when you turn around. Recently we have recruited an everyday web designer, and we have launched a search for another everyday web developer (hey ma, we’re on Monster!). I’m confident that if we can find the right person for this role, progress will be faster still.

Talking to Jordan today I compared the process of getting a project like this fully functional is like body building for the brain. It starts with a rush of adrenaline. Then you start getting stuff done. Every day we become stronger and smarter in the ways we get stuff done. Some days I can’t wait to get on whatever the task du jour is, some days notsomuch. But then I look behind at what we’ve done, and I realize that work accumulates and we’re on our way to building one hell of a thing. Beats watching late night TV.

Posted on

The Worst Ass Kickin’ There Ever Was

I was talking with Josh today about Hotmail vs. Gmail. He informs me that Hotmail is apparently offering two gigs of space to its users these days. “Hey,” I thought, “that’s almost as much as Gmail. Good for them! Two years after GMail was released, Hotmail has finally almost caught up.”

It occurred to me then that I think the release of Gmail signaled the single worst ass kickin there ever was of a previously existing online service. Zillow vs. Housevalues is close behind, but I’ll never ever forget the day that I got my 1 GIG of space from Gmail at a time when Hotmail was offering users 1 MEG of space, and charging its users something like $20 a month for 250 megs of space. I still grin when I think about the discussions that must have gone on behind closed doors when someone had to break the bad news to the Hotmail director.

Poor sap to boss: “Yes, um, sir, I don’t know exactly how to break this to you, but our most reviled competitor just released a product with 1,000 times more space than ours, better tools, and far faster.”
Boss: “They what?! #$#@$ at least tell me it’s not free. Please tell me it isn’t free.”
Poor sap: “Well……..sir……..”

What’s worse, even though Hotmail (and Yahoo) reacted pretty quickly to get users a semi-reasonable amount of space (I believe both had a free 250 megs within a month or two of Gmail’s release), the quick turnaround only serves to make them seem more evil for not giving their users that space in the first place. That bad taste is still in my mouth today, and the whoopin Google put on both Yahoo and Microsoft still frames the terms in which I think about the relationship between the three.

Of course, the alternative for these sites was the HouseValues.com approach: provide your users with a tool that takes 10 times longer to use, has less features, and blame a sagging national real estate as your woes mount.

Posted on

In Search of Less Data Waste

Data waste is an awful yet potent nemesis.

Here €™s the problem: every day, every person is bombarded with 16 hours of information. This information might be ideas in your own head about what you want to say, who you want to talk to, projects you want to tackle, improvements you want to make (to yourself or at work), or… anything. It might be something as nuanced as this blog. It might be as simple as remembering who you intend to thank. But every day, there is a lot of data being generated by our head.

Meanwhile, there is as much or more information relayed to us by those we interact with. People tell us how to improve ourselves, a great hike, where to shop, how to be productive, what it will be like to grow old, how to make a million dollars, what funny TV show or web site we should visit. Or any of millions of other things.

As one receives their 16 hours daily data, there emerges three choices.

Choice number one, which I think is probably used by at least half of all people, is to sit back, listen to all that data, and trust that the really important stuff will get captured by your memory and occur to you again when it becomes applicable. If none of the data you are receiving is imperative to your well-being, then you can certainly continue to exist while you arbitrarily remember some data and forget other data. But this choice puts a great deal of faith in the subconscious mechanisms that are choosing (based on factors we largely don €™t understand) what to remember and what not to remember.

Choice number two is to employ a few key systems to stay organized in things that matter most to you. Choice number two is what is used by people who keep a calendar of upcoming events and a filing cabinet of tax documents and a list of passwords and the like. Choice two is basically choice one, but for people who need a simple way to capture esoteric data that affects their well being. You €™re still at the mercy of memory for 75% of the data you receive every day. Different flavors of choice number two are what I €™ve employed to this point. I have slowly accumulated a sundry collection of what’s now about 15 different organizational systems, including Google Calendar, a filing cabinet, and various Gmail “drafts.”

memory2.jpg
Choice number three is to constantly quest for the Panacea to All Data Wasting (PADW). Looking at the piecemeal list of organizing systems I currently maintain, it €™s clear that my ad hoc organizational network isn’t working as well as it could, nor as well as I need it to. Speaking as a computer scientist, the essence of the problem seems to be that there are gigs of incoming data available for us to learn, but we only have megs of memory in our brains to store it. If that. Off the top of my head, I think the following are the key components of PADW.

1) Figure out somewhere with the capacity to store gigs
2) Ensure that the time it takes to retrieve data from said place scales well with large amounts of data
3) Come up with an algorithm for organizing that data such that we €™ll know where to look for it and
4) Make a plan for what happens if the storage medium fails.
5) Design medium such that it is accessible anytime, anywhere

It is true that I might be getting overly geeky about this, but with each day it becomes increasingly apparent to me that without PADW, I am going to be throwing away perfectly good data. For example, here’s some data I’ve received in the last 16 hours that fits in none of my systems (and is thus likely to be lost by the time I need it): Katy tells me that the REI online outlet store has great prices and delivers to Redmond REI free of charge; Ben tells me that there are monthly meetings of “lonely programmers” (programmers without projects) in Seattle that I can attend if I Google the right terms; a friend mentioned Salesforce.com, which is officially the many-eth time I’ve heard of that site without visiting it (unless I did visit it and forgot about it). Where would I file these sorts of information? Let alone information I get from people like my grandparents when I visit them and they tell me about experiences in their life that aren’t applicable to me today, but that I would do well to remember for future situations.

It breaks my heart to let this perfectly good data go to waste. It’s even worse when I visit a bookstore and read random books about Argentina or life as a single mother — lots of fascinating and someday useful data that would never fit in the 2 MB memory the human designer has outfitted me with. Anyone got a clue about how to fix this?

Posted on

Books for a Better World, Pt. 1

There are a couple books (literally, two) that I find myself quoting from on a very regular basis. Today, I come to speak of the book that takes about an hour to read and years to fully assimilate.

But before I reveal the identity of this book, a question: when was the last time you started using a new application (for the sake of this blog, “applications” includes web sites) and felt like the architect of said application truly cared about your experience?

Speaking from personal experience, it never occurred to me why certain applications felt “better” and “worse” to use. Nor did I ask myself why frustrating applications had ended up being designed as they were. Now I reflect on both regularly, and the reason is Don’t Make Me Think by Steve Krug.

Before I go any further, I should probably throw in fair warning: after reading this book, my reaction to using poorly designed software has changed from a mix of frustration and confusion to simple anger. If I waste more than five minutes finding a basic piece of functionality in an application, this now generally leads to severe annoyance. There is a fair chance that you, too, will revile the authors of your poorly designed software after reading this book. Therefore, if you are a person of action with a strong sense of justice, think twice before reading a text this potent.
dontmakemethink.jpg
But if you think you can deal with the truth, here’s what you’ll learn:

The premise of the book centers around the fact that users are very busy people who have neither the time nor the will to give an application as much attention as designers think they will. Krug asserts that when encountering a new application, the human impulse is to scan a page in about 1-3 seconds, make a best guess what will get them where they want to go (in Krug’s words, “satisfice”), and muddle along from there. He points out that designers should take care not to waste users’ milliseconds through making unclear links or leave them stranded in an application without a clear sense of where they are. He goes on to do some exercises where the reader sees examples of well-organized sites (i.e., Amazon) and poorly organized sites (buy the book and see them).

What’s more, the book is chock full of pictures and great examples. As I’ve come to know other Internet entrepreneurs within the community, I have found myself repeatedly citing examples in this book, as it seems to take most applications at least an iteration or two before they can get enough user feedback to create a UI layout that makes sense. Without this book and a strong sense of responsibility to your user, an application can quite easily never get things right.

With this book explained, you can now look forward to hearing the exasperated tales of applications that drive me bonkers, like TopStyle. This application earned itself an express ticket to my bad side today when, after handily reporting files with CSS errors in them, it provides no clear path of how to fix (or even view) these errors. Clicking on a specific error in a list of errors just jumps directly to the top of the file that the error resides in, not to the error itself. Brilliant.