Starting on MobiDick

codenewbie

Today I started working with Kerrie on a new web app: MobiDick. Kerrie is a good friend of mine who has been trying to figure out what to do with her life - and considering getting into tech - for a while. Over the past nine months or so, she’s taught herself a good bit of programming.

Like all new programmers, though, she ultimately needs to make the leap from “someone who can code” to “someone who can develop software”. The only way I know how to do that is to try doing a “full size” project, with all of the bells and whistles and pains.

Hence, MobiDick. The idea is simple: why doesn’t Project Gutenberg have a “Send to Kindle” button? And why do I have to store the ebooks that I purchase outside of Amazon, but ultimately upload to Kindle - like those from the Pragmatic Programmer - on DropBox? Why can’t I have a nice web interface for managing my non-Kindle-store books?

This is a nice sized project for a beginner, for a few reasons:

First, it’s of appropriate scope. You can get started with a single form and a listing.

Second, there are lots of directions to take it. Implementing a fully featured site will require all the key web application patterns, including authentication, file uploads, email notifications, regular notifications, comments, ratings, and the like. But there is room to do more! Just in our first planning session APIs to interact with a mobile app, background processing books to convert their file format, and actually figuring out the .mobi format so that we could make edits to the books came up. Plus the idea of writing a chrome extension to automatically send fan fiction to your kindle. There’s lots of opportunity to implement cool, challenging things, beyond your standard Twitter clone.

Third, it’s dear to Kerrie and my heart. Why build another Pinterest clone when you can build something that actually fills a need you personally experience?

Kerrie’s goal, as far as I know, is to learn more about web development, and develop as a programmer. My goal is to refresh my knowledge of Rails and early project development, and of my methods of teaching. Although I’ve onboarded several users onto existing applications over the past year, I haven’t worked with anyone as novice as Kerrie, and I haven’t done any greenfield projects - I want to make sure my skills stay up to date, and I find that teaching is the best way to do it.

The project will simulate, as accurately as possible, the real experience of being a programmer working on a small team for a medium sized web project. We’re recruiting a friend to serve as the product owner, and pedantically reject our stories in Pivotal Tracker. We’ll be doing user tests with some other friends who are kindle addicts. And the app will ultimately be deployed to Heroku just like any other real application.

Speaking of Pivotal, our first planning session was purely on the topic of Pivotal Tracker. Pivotal Tracker is the project management tool offered by Pivotal Labs. I’ve been using Tracker for almost two years now on all of my professional projects.

Introducing Tracker almost always has a learning curve, but introducing it at the same time as Agile is even more of a shock. Kerrie has never worked on a real project before, and hence has no familiarity with Agile or Scrum. I made the mistake of introducing Tracker first, then sort of talking about Agile once we had it open; I think it would have been more effective to introduce Agile first. The key points we covered were:

We probably could’ve skipped points for now, but since I was introducing Tracker, had to discuss them, as Tracker won’t let you start a story without assigning it a point value.

One note: The new tracker intro video, which Kerrie saw when she created the project, was very good. The explanation is much better than when I first started using Tracker. That said, I do not know why Tracker still defaults to a split “Current” and “Backlog” view. I always combine the views, and Kerrie initially was confused when estimating a early-in-current story at 8 points pushed sevearl other stories off of current, and hence, off of her screen. It definitely was not intuitive at the time - I think this part of their onboarding could be improved.

We then sat down to write stories. I do my best to offer guidance, instead of taking over the situation. We started with some great ones:

First comment: Why is everyone’s first story user log in? I suppose it’s obvious

We then started fleshing these stories out. This will, of course, be an ongoing process.

I tried to focus my prompts in two types:

First, disambiguating nouns. “As a user, I can scan the bookshelf” is a great start to a story - I actually think scan is a particulary good choice of word, because it helped us come up with some more interesting ideas of what “scan” means - but it prompts questions about what is a bookshelf.

So, we ended up with some new stories:

I also pointed out the question: where do books come from? So,

I then went ahead and added - I should not have done this -

In retrospect, it would’ve been better to let us discover this naturally. That said, I’m trying to balance expedience of teaching with the teaching, so hopefully it will not be too worthless.

We also came up with some fun reach stories:

That last one is my favorite - the idea being that it’s the same as writing in the front cover of the book, if you then lend it to others We also ended up with a couple that will need fleshing out, like “As a user, I can receive notifications” (notifications of what? from whom?)

The final list we ended up with as our current section, in order:

And that was the end of our 90 minute work session. I’m really looking forward to implementing these stories!

You can follow our PivotalTracker publicly here

I'm looking for better ways to build software businesses. Find out if I find something.