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.

Posted on

The Storm

The storm of activity has begun, as we have finally found the web designer/scripter we need to finish the alpha push. Without further ado, let me introduce (ahem)…. me!

I tried to do it otherwise. The eMyth guy would surely have a cow about the entrepreneur/technician overlap, but at some point, I’ve found that the complexity of proposing deals to web designers in the relative absence of cashflow and a demonstrable user or technology base is just less efficient than getting my hands dirty in the Javascript/CSS/AJAX/Ruby/Rails/HTML. And besides, most all of the contributors to the project so far have found me, not vice versa.

But I like learning, so I’m generally enjoying the web development experience so far. Moving from console/application development to web development really does bring into focus the issue of “what satisfies you” as a developer? I speculate that most people find the greatest satisfaction when they can use their creativity to make coolest possible stuff happen on their technology platform. Web development has those overtones, but it seems to me to be just as involved “how to get your code to run on buggy browsers developed 10 years ago” as it is creative problem solving. I don’t know who finds that satisfying, but as a means to an end, that’s what this game seems to be about.

Posted on

Be Wrong

I love being wrong. Actually, check that, I hate being wrong. But I love finding out how and why I am being wrong.

When considering whether to undertake a new type of challenge, my guess is that “being wrong” is a big component of what makes people hesitate. Why?

In school, we all had regular opportunities to be wrong. Every test you took, you would probably be wrong on at least 10% of the answers. And there was no subjectivity; no “this seems wrong but it could just be me.” You simply didn’t “get” the test question, or you misunderstood the homework instructions, and you had to learn what had caused your reasoning flaw.

Graduating to a professional environment, it seems like the opportunities to be bona fide “wrong” are few and far between. Those who are regularly told they are “wrong” are often people who become disgruntled and leave their job. The rest of us glide happily along, forgetting what it was like to get a “C” on the final.

But what more fundamental component of personal growth is there than learning, and what more fundamental component of learning is there than experiencing failures? If you haven’t been exceedingly wrong at least six times in the last six months, I’ll bet you’re becoming less than your potential.

Posted on

Lull Before the Storm

Here it is. Do you hear it? It is the sound of nothing happening. It is the sound that indicates that my video game is almost done, and has at long last provided a bit of that “end of project crunch” that the game industry has become famous for.

The game is preliminarily done tomorrow. It’s done in final form a week or two after.

And that’s when this party really gets afoot. Immediately following the conclusion of my regularly scheduled programming, two weeks of “vacation” follow. And by “vacation,” I of course mean discussing, designing, and maybe even developing, if that’s what it takes, to put the legs on this here hobby horse.

Stay tuned…

Posted on

Buy! Buy! Buy!

I think I’ve hit upon a pretty apt analogy for the ebb and flow of getting one’s business rolling. It is the very indicator used by millions of business the world over. It is the stock market.

200_year_stock_chart.gifFirst of all — and you won’t hear me admitting this again at any point in the near future — a lot of what comprises “success” is stupid luck. I have spent hundreds of hours recruiting our team to this point, and the best people we have all 1) came from different sources 2) did not find out about Bonanzle through any of the numerous postings I’ve made to sites like Jobster and the UW Career Center. People routinely ask me (and I routinely ask other people) how to find the best people for a project, and the generally accepted answer is that nobody’s got a clue. You just keep talking to people and eventually get lucky. The stock market analog is the (fairly common) incident where a lifelong financial analyst is beaten by the S&P 500. Even seasoned analysts can’t generally compete with luck.

Second, no single day is very indicative of the overall trend. I think this is one those principles you hear a lot when talking about entrepreneurialism without really understanding it. It’s often worded as “you should expect a lot of adversity and challenges to overcome,” but when you actually experience these “challenges” (or less nicely: failures) on a daily basis, it is easy to get discouraged and lose track of the overall upward trend. What it feels like is that every time you get traction with a new idea or new recruit or well-executed maneuver, it gets negated by the Looming Unforeseeable Obstacles. But, viewed objectively, a business only needs to have slightly less failures than it has successes to win. In the stock market (and in my stock market, fantasy basketball), the same is true: trend trumps daily blips.

And the correlate to both the first and second principle? That the best you can do for either your business or stock is to put yourself in the best possible position to succeed, cross your fingers, and pray to the law of averages for a break. Oh dearest law of averages always comes to the rescue of the worthy. But eventually.

Posted on

Slog Conquers Blog

Alas, dear blog, you have been whupped by the slog of this week’s tasks and obligations, but I’m fighting back as valiantly as can be.

Most recently, Bonanzle.com has had some of its content refreshed to reflect the current needs of the site (i.e., web designer), and to ensure that the most visited pages (i.e., “About Us”) have some information that is as useful as possible, without actually being so useful as to describe just what this project is all about.

In general, things on rolling. No two weeks are the same, and no one week is easy, but every week puts a few more tangible pieces into the puzzle, which is a most satisfying process to watch.