A Shining Ruby

Yes, so this company is all hot to trot on Ruby on Rails. Or rather, the CTO is. I can sum up my experience to date as follows:

Stage 1: Loved It
Stage 2: Hated It
Stage 3: Tolerating It

I'll do a longer post in a little bit, but here's the preview skinny.

Stage 1: Loved It
Ruby on Rails is a very smart framework. Ruby _is_ really a fun language to use. Ruby is great for little utilities and quick scripts and has all sorts of interesting things you can do with dynamic code. Think Javascript with a little more sense to it. Rails takes many of the best techniques from web apps, including Test Driven Development, and rolls them into a single stack (cross-platform).

Stage 2: Hated It
This stage came after actively building an app for our first sprint (two weeks). Like many tools that try to help you out, it will fight you if you try to go outside the prescribed path. Once I was actually building with it I realized it was more like doing battle with the ghosts of classic ASP/VB Script than using some new whiz-bang tool. And once you get beyond the cutesy tutorials, the documentation truely blows when compared to what can be found for other, more mature platforms. And no, being able to read the source code directly doesn't preclude the need for proper documentation and tutorials.

Stage 3: Tolerating It
Like any platform, there is a learning curve. I'm accepting that I'm still going up it. On the positive, it is much easier to learn that a full Java stack. On the order of a couple days instead of a few weeks. Unfortunately, the performance (not scaling) of Rails is so poor that I end up writing all kinds of workarounds in addition to extra unit tests that would not be necessary if I was still developing in .Net with a proper ORM tool. This largely cancels out any perceived benefits or LOC savings that people crow about when evangelizing for Rails.

I'll follow up with a full review of the good, the bad, and the ugly of Ruby on Rails in a few days/weeks once I confirm a few more things.

Scrum in the Small

So, in the new gig there are three of us developing and one designer. And an off-site contractor-guy that we don't talk about. And multiple applications, so everyone pretty much gets their own piece. Classic startup. Do we even need a process?

Emphatically, yes.

Startup stage companies face a different set of problems. Organizational inefficiency is not one of them. There is not bureaucracy to slow you down. There are not so many people that coordination is difficult. But efficiency is still a concern.

Most startups face both the "too much work" and the "shifting priorities" problems. Scrum helps with both of these by placing everything into a single priority queue. We opted for one across all products. The backlog also allows for management of shifting priorities. As a bonus, if you track your velocity you will have a good idea of when the product will be ready to ship.

Thankfully there was little resistance (none) to implementing Scrum here. There is a little uncertainty as to if it's actually needed. As my sales pitch I put it that scrum is essentially exactly how we are working anyway (read: little to no overhead), but helps us prioritize and focus.

We're now in our second cycle. Big winner points:

• Backlog (priority queue) for tracking progress
• Planning game (story point estimation)
• Sprint Demo to stakeholders
  

Items that I see as having value, but not yet proven to team:

• Velocity tracking (and long-term release planning)
• Daily standup
  

The standup is interesting. In startups where we all sit together there is a perception that the standup is not necessary since we're already communicating. This is a false perception. We actually have almost no communication since everyone is heads-down on their part. The standup brings forward where our touch points lie.

Moving on and up

It's been a little while since I've posted. Things have been fairly shaken up, which has kept me busy. I reached a point where I realized it was time to move on from this initial experiment. We had a project manager who had picked up the Scrum grail. The company was far more comfortable with someone in that role instead of a developer driving a project management methodology.

While it is healthier for the company organizationally and politically, I realized I would no longer be able to affect the sort of changes and improvements I have come to expect of myself. Don't despair, tho. I've started with a new pre-product startup and will be continuing on, albeit sporadically and with a different slant.