The backstory is interesting. As Kieran writes on the site, he and Kevin are not the TTC. They’re just two software developers who decided this needed to be done. As they detail on the MyTTC About page, the idea was born out of frustration with the official TTC site, which has always been impossibly hard to plan trips with.

I share their pain. Several times after moving to Toronto I tried using the official transit web site to figure out how to get around the city. After much wailing and gnashing of teeth, I simply gave up. All the route maps were and still are provided only in PDF format, instead of simpler and smaller GIF or JPEG images. The system maps — which are the only way to figure out which route map you need — are gigantic PDFs that take ages to download and render. (Don’t try to find these maps from the main page of the TTC website, which for some reason links prominently to even stranger and less useful maps on the Toronto.ca site.) Meanwhile, the new beta TTC site has no system map yet, and no trip planner. A forlorn spot on the beta site home page proclaims, "Future home of Trip Planner".

Tragic.

So if you’re an entrepreneur who wants to buld your own trip planner, how do you get the data? Woe betide you, for the TTC won’t give it to you. The information sits in a database somewhere in the bowels of the organization, where it is periodically used to generate the aforementioned PDF route maps and now the new route pages on the beta web site. But the TTC won’t make the raw data available for public use. So Kieran and Kevin had to compile an entirely new dataset of their own by pulling the information out of hundreds of PDF route documents. Then they had to scrub it, by hand, because the data was buggy buggy buggy. The scrubbing continues.

Wow.

Unlike the TTC, Kieran and Kevin are making their dataset available to anyone who wants to play with it. This means anyone can build their own Toronto transit map or trip planner now. It also means we are a step closer to having Google Transit support, since all that’s needed to enable that is a suitable data feed. (Google has offered in the past to set up Google Transit for Toronto. Vancouver, Montreal, Ottawa, and even Fredericton have Google Transit support. Toronto? Sorry. No data from the TTC.)

Shame on you, TTC. Shame on government organizations that hoard power by keeping public data under lock and key.

And congratulations, Kieran and Kevin, for rolling up your sleeves and building a great public service that Toronto really needs.

[cross-posted on Mukodu Blog]

I’ve learned to use Ruby and Rails over the last year and a half. Along the way I’ve been watching how the Rails core team evolves their project, and how Matz evolves Ruby. As a result, I’ve become more convinced of something I first started thinking about — but was always too timid to fight for — when I worked on Windows: every once in a while, you need to just throw out the old stuff and start afresh.

On Ruby, and moreso on Rails, the development team is willing to not just deprecate smelly old crap, but actively remove it. New versions of the Ruby language and the Rails platform are generally expected to remove obsolete or badly implemented features. This happens when code contributors come up with a significantly better replacement, or the team realizes the features are no longer essential to the project. Non-core stuff gets either recast as an optional plugin, or binned. For a good example of this, see the Rails 2.0 announcement and scroll down to "Active Record: Shedding some weight".

I’m sure this approach makes most old-school developers out there cringe, or scoff, or both. "Are those Rails guys crazy? What about backwards compatibility? Don’t they care about their customers? I guess they don’t have any customers, or not any real ones, at least."

I’ve wondered those things too. Especially right before I decided to make a bet on Rails for building 5 Blocks Out. But at the same time, I’ve worked on Windows. I’ve seen up close and personal what happens when you commit a product to backwards compatibility at all costs, and it ain’t pretty. Let’s look at the outcomes.

First, the benefits:

1) Apps built for platform version N can run on version N+1.

2) App developers can use their knowledge of platform-and-tools version N to write apps for version N+1.

OK. That’s about it for benefits.

Really. We’re done with the upside.

Now for the downsides:

1) The platform bloats in on-disk size and resource usage (RAM, CPU cycles) as new features get layered atop old. Obsolete technologies, instead of being removed, stick around forever, and… s l o w… e v e r y t h i n g. . . d o w n. It’s like the nightmare guests that overstay their welcome at a party: drinking all the booze they can find, gobbling up everything good in the fridge, and then staggering around for hours smashing into things and making a nuisance of themselves before crashing somewhere horribly inconvenient. What a drag.

2) Life gets worse for application developers. Yes, those who learned version N can apply all their learning to N+1. But let’s be realistic here: N+1 is big, and N+2 is even bigger, and N+3 is, whooo, geez, immense. Eventually, no mere mortal can comprehend the entire platform API. And that means they won’t take advantage of new features properly. What’s worse, they’ll probably be embarassed about that, so don’t expect to hear them admit it.

3) Life gets worse for platform developers and testers, too. Not only do they have to deal with platform bloat, but more and more of their jobs become — sorry, I have to say the dreaded ‘m’ word — maintenance. Eventually they are forced to perform truly unnatural acts. Like this: "Hey, does anyone know what this SuperDuperComplexJujuMagic library does? This thing is seriously fugly, and all of our code is linked into it like spaghetti." "Oh, that’s been around since version 1. Bob wrote that. It’s part Prolog, part assembler, part Esperanto. Unfortunately, nobody else understands the code. And Bob left last week to go work for Google. He’s buying a yacht and a new Hummer! Isn’t that great? So, uhh… just work around it."

Sound familiar? Old features become stale and mysterious, especially when the creators and maintainers leave the building for greener pastures. New features must be implemented in bizarre ways to work around old cruft. And new platform versions must remain not only compatible, but bug-for-bug compatible with old versions. So the poor devs end up having to write ugly, smelly code. Code so ugly and smelly you’d be ashamed to tell your mama about it.

4) Customer resistance to upgrades increases over time. "My developers want to skip version N+1. We have no problem waiting for N+2."  "The sales team can’t afford to buy upgrades for all of our apps this year. We’ll just wait."  "Our IT department takes 18 months to test your OS for bugs before rolling it out, so we only want to do that at most once every 3 years." This is real. This is the conversation Microsoft sales reps have with their big customers every time a new version of Office or Windows rolls out. It is the reason marketing teams argue about whether a release should be positioned as a "dot" release or a "major" one.  It’s why Microsoft has been trying for years to move to a service-and-subscription model, where customer payments look like an annuity stream instead of once-every-few-years-big-bang. It is also the reason they are belatedly getting serious about running their apps in hosted server environments.

Imagine what would happen if innovation in general worked this way. Picture, if you will, Honda telling their designers to create a car that customers would love, with the caveat that they would have to keep all the anachronisms from every previous car model they had ever made. "Sorry, I know the gas tank in the ‘02 was prone to explosion on impact, and it only gets 3 miles to the gallon, but we have to keep it around because of our commitment to backwards compatibility". Sounds crazy, doesn’t it? But this sort of conversation happens in big software shops every day.

You could argue Ford and GM have been doing this for years with their trucks and SUVs: selling ever-more-glitzy and ever-more-hulking body designs atop inefficient and increasingly archaic platforms. (The platform is car innards in this case… the engine, chassis, and other nasty bits). Now, as gas prices are imposing a resource cap, reality bites. The lipstick-on-a-chicken strategy is finally failing.

Seemingly unlimited resources have a lot to do with this sort of piggish behavior. Resource scarcity, in contrast, is actually a good thing. But that’s another whole topic.[1]

Imagine how much better Windows would be if the people working on it were allowed to do spring cleaning once in a while and throw out smelly old stuff.[2] Yes, there would be a cost, both internal and external, but the benefits would be legion. App developers would appreciate writing code atop a more modern, constantly rejuvenated platform. Platform developers and testers (and their mothers) would be far happier, because they’d be writing elegant and clean code, code worth writing home about.  And most importantly, customers would enjoy running fast, reliable, and cleanly designed products, instead of cluttered unstable resource pigs.[3]

Software innovators need to get into the habit of throwing old stuff out, just like people who design other types of products and services do. And software companies need to avoid — or extricate themselves from — business models that prevent it.

—-

[1] Remember the old days of personal computing, when there was a very real cap on memory and disk space? This was the case for the Commodore 64, and the old Apple computers, and most video game consoles and mobile phones created thus far. You simply couldn’t offer backwards compat, because resource constraints wouldn’t permit the bloat. These days, on PCs, the resource constraint is gone, but the reality is we have hit a bunch of other constraints: the size of app developers brains, the depth of app purchasers’ wallets, and the limited desire of customers to roll out big bang product releases.

[2] My comments aren’t directed solely at Windows. It’s highly likely that MacOS, Solaris, and other mainstream commercial OSes suffer from exactly the same problem. But I’ll stick to what I know best here.

[3] Sorry, I’m feeling a little harsh today. Anyone want to debug my Toshiba Portege, which slows to a crawl and locks up? Or perhaps Katrin’s MacBook, which refuses to go on standby.

There are "business" solutions you can use, including limiting your support service level agreement and hiring more support people, perhaps in different time zones around the world. These may be appropriate depending on your customer needs and your budget.

You can also throw technology at it. Here’s what we are trying to do in that vein, on 5 Blocks Out:

(1) Ship quality software. This is motherhood and apple pie, but bears repeating. Lots of software companies still imagine they can somehow cut costs by shipping half-baked code. Sorry, it doesn’t work. If you don’t invest in writing good code in the first place, you will pay orders of magnitude more for it later in support costs and frustrated customers. The only valid exception I can think of is prototype code.

I feel like we have lots more to do here, but for small fry we’re doing well thus far. We try to be thoughtful and minimalist about what we build in the first place. Then, if it gets built, it gets tested. Rails’ built-in testing facilities and various plugins like test/spec help a great deal. Capistrano (for automated deployment and rollback) and Firebug have also proven to be vital. Next on the list is eycap.

(2) Outsource work to a Web Host. For a software startup, the question is not whether to do this, but with whom. Outsourcing the heavy lifting of buying/building and maintaining server farms, managing network bandwidth, and handling some of the basic application-level services is a no-brainer. Pay as you go, and use the time saved to focus on your core competencies. If and when your businesses gets big enough, you can always pull some of the strategic responsibilities in-house.

We currently use Hosting Rails. Generally speaking, their servers run well and their rates are reasonable. I have run into reliability problems lately, though, and despite responsive support it is becoming time to consider other hosters. Slicehost, 3Tera, and the increasingly fashionable Amazon S3 are on the "must review" list. I’ve also taken a brief look at Google App Engine, and concluded its platform is too high-level for our needs.

(3) Automate monitoring. Automated watchdogs can stay up 24×7. You, my friend, cannot. Put down the Red Bull and get yourself a suite of automated watchdogs to monitor your software’s health.

We’re getting going on this now. For starters, the Exception Notification plugin has proven itself mighty useful for after-the-fact diagnosis and debugging of Rails apps. If you’re running a Rails app, I highly recommend this plugin.

Next, you need some 3rd party ping action. Troy tells me Alertra is also supposed to be a good quality monitoring service. We are currently trying out Pingdom. The idea behind these services is to hit your site every minute (or 5 minutes, or 15… you decide) from a series of servers around the world, and let you know whether and how quickly your service is responding to HTTP, pings, and so on. When something goes wrong you get notified by email and/or SMS text message. Pingdom also collects and aggregates the data so you can look at reports over time.

Happily, Pingdom has already paid for itself: immediately after turning it on I found our service was bouncing daily (well, middle-of-nightly), sometimes down for many minutes at a time. HostingRails gave us a month of additional free hosting as compensation, and promised to watch the server more closely. We’ve had zero downtime since then. 

Going a level deeper is also essential: you need realtime monitoring built into the service itself, so that you can detect and resolve problems when their symptoms first surface, or even before then. Monit, God, and Munin are on my "must review" list for this sort of thing.

I’d love to hear back on other tools and tactics startup developers are using to build and run high-availability software services. Without losing sleep, that is.

Happy zzz….

People have been asking what we’re up to with Mukodu. While we can’t talk in detail yet on the specifics of what we’re doing, we are ready to share with you our vision, our motivation, and the company culture we intend to build.

Over the past ten years Katrin and I have lived in two countries, three different cities, and five different homes. We’ve also had the good fortune of travelling broadly. In doing so, we’ve recognized a common challenge: more and more people live in and move between urban areas, where they seek new opportunities, new friendships, and increased quality of life. Yet newcomers often don’t know where to begin, or how to get connected in a city, despite being surrounded by people. At the same time, "old-timers" often get so caught up in the routine of daily life — working, commuting, connecting with friends and family — that they fall out of touch with the changes going on around them, and with the people and resources right outside their front doors. It’s a great irony: despite living in populous, thriving, dynamic cities, we are so often disconnected. Thus the inspiration for the Mukodu blog, and for our first product, 5 Blocks Out.

5 Blocks Out is about connecting people with local life and culture. If you’re new to an area and trying to figure out which neighbourhood to call home, 5 Blocks Out will help you. If you want to learn what’s happening in the nooks and crannies of the city around you, 5 Blocks Out will keep you informed and up to date. If you want to hear what real people like you have to say about local places, events, and issues, 5 Blocks Out will help you to tap into urban word of mouth. And if you’re interested in helping others find “nearby good stuff”, thereby supporting local communities (yay!) and reducing environmental footprint (yay!), 5 Blocks Out plans to help you there too. 

Why work on a challenge like this? Because we love the places we’ve lived, and the friendships we’ve made there, and we want more of the same for everyone. We believe cities whose people engage in neighbourhood life, local culture, and civic discourse have unlimited potential as places to live. We believe healthy connections between people within neighbourhoods are essential. We believe the collective voice and wisdom of a city’s inhabitants is more interesting and, indeed, more personally relevant, than the voice of popular media. And so we’re setting out to create a community powered by the people, for the people, with the goal of making cities great places to live.

Mukodu is just getting going: for roughly the past year it’s been Katrin and myself, working together in true startup fashion: 25 hour days, 8 days a week, 1 to 2 minor miracles per day. We’re learning how to bootstrap a business on a shoestring, design and build products together, and leap tall buildings in a single bound. We’ve spent a great deal of time analyzing, debating strategy, and thinking through minute design and implementation details. We’ve learned a lot, and built the beginnings of something we think you’ll love. It’s been thrilling, and terrifying, and the most fun we’ve ever had "working". We count ourselves very fortunate to be doing something we’re passionate about, day in and day out. We owe huge thanks to all of you who have supported us thus far.

Mukodu is also growing, and we’re looking forward to growing further. We’ve recently had a great boost with part-time help from Katy, Aaron, and Troy. We’re plugged in to a wonderful community and office space at the Centre for Social Innovation. And we’re starting to bring on some trusted advisors to kick the tires on our product and provide more guidance as we near public release.

While we aren’t in a position to hire people yet, we soon hope to be. We’ll need help: in particular, more software engineering and operations talent to build and run a kick-ass software service; advisors and board members to guide us; and angels to help prime the pump. We’re looking for these folks, starting now. We want people who share our values, passion, and hunger to change the world. We want people who are smart, scrappy, and get things done. We want people with creativity and a love for data analysis and problem-solving. We want people who understand that "going live on the web" is just the beginning; we must also have the humility to continually seek feedback and iteratively build something that actually works for customers and solves their needs. We want people who can handle the uncertainty and risk inherent in a startup environment, and whose instinctive response to a challenge is, "Can do!". If that sounds like you, or someone you know, let’s talk. 

We’re excited. We are getting great feedback. And with your help, we will make a real change.

Fire it up!

Osh and Katrin

Hi all, I have some exciting news to share.

Some of you know that Katrin and I have been collaborating on putting together a web startup. We are extending the core idea she’s been blogging about on Mukodu: namely, discovering local “good stuff” by tapping into the knowledge of your friends and neighours. So… [drum roll]… moving forward, we will both be blogging about our brand new startup — Mukodu, Inc. — and the projects we’re working on together under that umbrella.

Don’t worry, I promise to keep on writing obscure, geeky, niche stuff here on MyOwnPirateRadio, just like I always have. I don’t want the readership numbers to dip into single digits, after all. But from time to time I will also post on the Mukodu Blog, especially when it’s a topic of general interest regarding our startup work.

The first project we’re working on is called “5 Blocks Out”. The web site is currently under development, and all going well, we’ll begin opening it up for public trial later this summer. If you’d like an invitation to participate in the Beta release, visit www.5BlocksOut.com, drop us your email via the signup form, and we’ll let you know when we’re ready for you to kick the tires.

In the meantime, stay tuned to Mukodu for more!

Osh

I am bumping into a lot more people these days who are working at home or considering it. Perhaps it’s just coincidence, or maybe the people I hang out with are hitting some magic age where career change is necessary. Perhaps more of us will begin work-shifting, in addition to time-shifting?

Personally, I’ve worked from home for the last few years, with about half of that time spent jointly on a project with Katrin. It’s been fun: we get to structure our work space and work day just the way we like it, and there is a subtle luxury in the freedom to opt into "weekend activities" on weekdays. But it can also be challenging: you can get stir-crazy, lonely, burnt out due to lack of working schedule boundaries, or unproductive due to distractions. After experiencing a taste of all these things, we recently decided to rent out some part-time office space at the Centre for Social Innovation, and have begun splitting time between the two office spaces. So far, so good.

Toronto is lacking coworking options right now. Indoor Playground ran for about a year and a half and closed up shop around the end of 2007 when their landlord hiked the rents. Centre for Social Innovation offers workspace rentable by the hour or by the month, with shared access to networking, printing, a kitchen, and so on. But as their name suggests and David Crow points out, CSI’s focus is on social innovation, and they require all tenants to have that as part of their agenda.

Wayne Lee posted on TorCamp this morning about organizing a meeting to gauge interest in creating a new Toronto coworking space. Check it out:

We’re trying to gauge interest in developing a permanent dedicated coworking space in downtown Toronto. This might include shared office
space, some anchor offices, meeting and training space, and a private cafe. It could be any or all of those. Let’s have a discussion with a brief presentation to explore what it might be and why you might want to be a part of this.

Where: Epicure Cafe, 2nd fl, 502 Queen St W, between Spadina and Bathurst

When: Tue May 27, 7:00-8:30pm

Please register at http://www.eventbrite.com/event/116040079

On the more casual end of the spectrum, there are lots of cafes that tolerate laptop customers for a while, but I haven’t yet found any other than the Linux Caffe on Harbord street in Little Italy that actively encourage mobile workers. It’s an odd contrast to Seattle and San Francisco, where mobile working is de rigeur, and it’s easy to find hangout spots where you can be productive and — shock! — welcome for a few hours.

Here’s hoping the coworking trend will tick upwards in Toronto too.

I wasn’t really sure what to answer at first. "Beta" used to mean an interim test phase on the way to a "final" and "supported" product release. But over the last five years or so, as we’ve shifted from the boxed-product software world to the online service software world, the term has taken on a very different meaning.

Here’s what Google CEO Eric Schmidt had to say about it in a recent Business Week interview:

How do you make sure all these Google engineering projects actually turn into useful services?

The No. 1 thing we do require is: You can do whatever you want as long as you track it. We have very sophisticated measurement systems at every stage of launch. We have what is called trusted testers. Then beta test, which is forever. We do these 1% launches where we float something out and measure that. We can dice and slice in any way you can possibly fathom.

No real support guarantee, although I doubt . He should know. Pretty much every Google offering has a Beta label on it, with the notable exception of Web search.

So… the new "Beta" means continuous testing, measurement, and improvement. The product is never really "finished", per se… it just evolves. As for support and product quality expectations, it’s much harder these days to get explicit statements or promises from vendors on that sort of thing. Thus "Beta" is also a convenient marketing label to hide behind –  just like it always has been — except that now you can hide forever. (That said, if a so-called Beta service like Gmail went down, you can bet the support would be fast and furious.)

The last point in Schmidt’s answer is also interesting, and to the point on how Google decides whether a service is actually successful:

What’s more important than the absolute number is the relative growth rate. High growth solves virtually all problems. If the growth rate is low, or negative, you’ve got a serious problem.

Test, measure, improve.