Naked Startup

Week 4 - Looking at the Front

After spending our first three weeks working on the administration features we've spent this week getting a very basic front-end (i.e. no prettiness!) working for Gameplan.

With our 'product' heads on we realise that getting the building blocks right at this stage will really help us in the next 'polish for echelon and launch' stage.

One of the key things that stands out for me in thoughtfully designed applications is the URL structure, so we had a long discussion early in the week about how that should look in a browser. Also as we will be launching a RESTful API in the future (not for launch - priorities!) the endpoints for that are also very important.

A key tool for us this week was the Ruby gem subdomain-fu. Many web applications use the http://accountname.webapp.com pattern to subdivide a hosting service and we will be no exception. It plugs straight into the routing system in Rails and works very elegantly, meaning a lot less headaches than we were planning for. We knocked out the basic HTML pages for most of the site in a couple of days.

Other milestones included the validation on our work last week meaning we're now able to track the main statistics for most team sports: pretty much everything except cricket. I have a feeling that at some later date there's going to be a 'cricket integration' project.

The last couple of days have seen us filling out some of our optional data structures, which we know a lot of sports organisers will want (based on the existing features on some current sports websites).

Ironically in the week in which I eulogised the benefits of pair programming this work was to prepare us for a week apart. I have to go back to the UK for the wedding of some good friends (in what will become a recurring occurrence this year). So next week, I'll be working on an initial design for both the administration interface and a standard theme for the front-end. Arun will be working on a flexible importer for existing organisations.

These are tasks that fall outside of the typical product development cycle although we'll be doing our best to keep things collaborative. We've already discussed our approaches to the tasks at hand and we'll be keeping in touch. UK mornings are broadly Singapore afternoons so we'll be online together then.

We'll be using Campfire (rather than IM) due to it's transcript and image upload features so I can share the design work. If we need to collaborate on something on screen we'll use iChat's screen sharing.

It'll be interesting to see how effective we are.

Weekly Stats

19 issues closed on GitHub, 17 new features added leading to a current total of 44 with 184 scenarios. 1475 lines of code and 5095 lines of test code with a code-to-test ratio of 1:3.5.

The Joy of Two

I am aware of the amusingness of writing an article called 'The Joy of Two' on a blog called 'The Naked Startup', but it's a good title no? In the past few weeks of building Gameplan I've had a personal epiphany resulting from our work style. One of the key tenets of what Arun & I wanted to do for ourselves was to experiment with new ways of working and a key part of that was pair programming.

We currently use a 'work' Mac with a 20" monitor that isn't personalised to either of us and we use one keyboard, one mouse and two brains.

It's just the best thing we could have done. I realise this sounds like hyperbole but the sheer volume of work that we're getting through seems to bear out the unintuitive notion that having one person 'just sitting there' is faster.

Good Things

You get stuck less often. Many a time we hit a proper 'how are we going to do this?' roadblock but with both of us trying different approaches we seem to get keep moving through the difficult times. Many a time I'm convinced I'd still have been sat there late into the evening trying to fix problems. Also those annoying typos that cause 'why is it doing that?' moments are stamped out much more quickly.

It seems that programming where there is always 'a solution' rather than 'a single answer' is an ideal fit for continuous collaborative work. There's also an 'opposite' benefit to stop ourselves before we disappear into a problem that doesn't need to be solved right now. It always helps to have another person to say "That'll do for now".

Focus. Every now and then as a solo programmer you get in the zone where four hours disappears and you produce something amazing. Unfortunately this tends to happen at 2AM, and rarely. With no IM, twitter, email and someone else next to you nudging you back into focus all the time you simply destroy your programming todo list.

Our quality is much better. The pairing has also enabled us to better ingrain testing into our work. We write tests first and then get them to pass, leaving us with fully tested code that we're much more comfortable with. The benefit of the pair here is to keep you on the straight and narrow, it's hard to drift off and start hacking when your other-programming-half reminds you the write tests first.

One of the reasons pairing works so well is that you are both constantly learning and teaching at the same time. This is also why it can be quite tiring! The benefits of picking up good habits, and suppressing your own embarrassing ones, as well as being exposed to another brain trying to solve the same problem are huge. We're also constantly having to justify our concepts to each other which helps you to sharpen your thinking before you dive in and start thrashing about in code.

Nothing quite beats the satisfaction of producing excellent quality end product. My theory is all engineers just want to build something and get a nice pat on the head. Even on the hardest days where I feel we've really got stuck and hardly achieved anything, when I look back back at the crossed off features I realise we're still motoring along.

The final obvious benefit is in the understanding of our application. We make more sensible decisions about the architecture, because we're discussing all the time. There are no chunks of code that we do not both have our hands in. It is extremely important (certainly initially) for both of us to know every area of our product intimately. Important for a convincing sales message, important for knowing how it works and important for laying the building blocks for any future work when there might be more than two of us.

--

I should say that we're not pairing all week. We often take some time off on Fridays as 'separate', where tasks less suited to pairing are knocked off the list. We also schedule any external meetings and calls for that day which means that we definitely have four days uninterrupted programming together.

I'm not sure if many other tasks are well suited to this collaborative approach. I still tend to think that visual design tends to work better as a work-then-critique cycle rather than the continuous feedback that pairing provides. But who knows? There's definitely a case for pairing in wire-framing or describing the functionality and flow of an app - in fact we've been doing that as well.

The one time since we've started that I've programmed on my own and had a 'hack' at something, I had the old familiar problems of 'why is it doing that?' and 'this was working a minute ago!' I missed my testing and I missed the constant reminders and thoughts of a partner. (Aren't I sweet?)

I know it seems counter intuitive. I know it's a hard sell to clients and bosses. I know it's tough to find someone who you can spend all that time with. I know you don't want to give up the keyboard, but try it for a week on something *real* and come back and tell me you don't feel a) better and b) more productive.

Disciplined as opposed to Lean

The Lean Startup philosophy is something I've been following a while now. Having watched Eric Ries' talks (although he does seem to repeat his talks substantially), most of it seems to be quite obvious. I'm wary of philosophies in general because it's easy for a lot of people to follow them blindly without considering that they are just broad guidelines - ultimately you make your own rules for your company (and for your life for that matter). Of course it helps to learn from others' experiences, but following advice wholesale is recipe for disaster.

[As an aside, Andy and I fortunately have similar tastes in terms of companies we admire - GitHub, 37Signals or Craigslist are a few we look up to. Like them, our goal is to execute on our vision with maximum force and minimum fuss. Watch this space for a lengthier post on companies we admire.]

The Lean Startup philosophy is often misunderstood to mean cheap, bootstrapped and blindly optimizing based on customer metrics, which Eric clarified a few days ago to be not true. It simply means (and I agree), that you have to quantifiably measure your progress, learn from it and decide whether to stay the course or pivot on your vision. Come to think of it, Randy Komisar's new book 'Getting to Plan B' also offers similar insights.

Although the core tenets of lean startup probably don't apply to Gameplan right now since we don't have any users yet - there's still a ton of learning happening.

As mentioned before, we try to avoid making big decisions, but instead make tiny decisions on a weekly or daily basis, thus giving us ample room to pivot in case things don't work out. Already in the last three weeks, we've decided to take out to-dos from our sprint and add new ones, because we've been handling one particular type of problem for too long, for example. We've even changed design and implementations half-way after we've started, but because we don't invest too much time trying to think of the perfect solution, it becomes a less difficult decision for us to redo stuff.

We've also tried to be religious with tracking our progress. Regular readers of Naked Startup will have noticed our weekly statistics report, quantifying our progress in terms of lines of code, lines of test code, how many features we've completed, how many issues we've closed, etc. Again hard-core lean startup enthusiasts will argue that there is no real learning to be had from coding. But I believe that pair-programming and behaviour-driven development give huge learning benefits from knowing your own product, how it works and learning in terms of knowing one another as team-mates. Too many times, I've seen founders who don't know how their own products work and that is something Andy and I want to avoid like the plague.

One really significant hole in our Lean-Startup practice so far has been the lack of a unified metrics-dashboard. We still check on Google Analytics (for both Gameplan as well as Naked Startup), Code Analytics and Signup Analytics separately - we should probably use our Friday afternoons to build a unified dashboard ala Panic.

I guess being 'lean' is just a common-sense move. No startup wants to be shooting in the dark, because that is just stupid. Maybe Eric Ries should have opted for a less-catchy-hashtag-but-probably-more-meaningful catch-phrase: Disciplined Startup.

Week 3 - The Importance of being Paranoid

Yet another solid week, we got through some pretty gnarly problems as well as some important features while still having fun. The deadline is coming up pretty fast, but based on our progress in the last few weeks, we should be in pretty good shape, come echelon (touch wood).

Some interesting tidbits from this week:

• We've started to use using Pickle very extensively in our Cucumber steps and this has really made our features more elegant. Andy also came up with some slick Cuke steps (based on Pickle) such as 'Given fixtures are scheduled and generated for season: "current" playing each other "2" times' which really let us focus on the task at hand, rather than spending our time setting up.
• We ran into a gnarly bug in our Fixture-Generation algorithm (which we'd completed in Week#1) while creating another feature, following which we've both become more paranoid with our tests. This has resulted in us writing more negative cases to make sure our code is valid - being paranoid in this case is good, imho.
• Al Hamra at Holland Village has great kebabs.

Stats as of week 3:

16 issues closed on GitHub, 9 new features added with a current total of 129 scenarios. 1137 lines of code and 3714 lines of test code with a code-to-test ratio of 1:3.3.

Week 2 - OCD

It's been another good week for progress. The tiny green dots that measure our progress are much more numerous and our application now has an (extremely simple but functional) design, so we can begin banging on it like users rather than letting our automated tests have all the fun.

We seem to be able to knock out most of our planned activities by the middle of the week and our two major 'maths'-type programming problems have been solved. I'm pretty sure we're going to have the foundations and major user 'flows' of the site in place within a fortnight or so, leaving next month for a presentable design and lots of polishing.

It's hasn't  been as plain sailing as the first week, we hit some real roadblocks on Tuesday as we battled manfully with the structure of our data in order to make sure the user's workflow on the site was as slick as possible. The pairing really helped. I think that on our own we'd both still have been stuck, but the continuous discussions that are part of this working style seem to loosen problems into solutions more readily.

I've found this week to be much more tiring. Whether this is to do with the lessened adrenalin of the second week or the effort that comes with the continual intensity of pair-programming I'm not sure.

An interesting observation this week was the different ways in which our programmers OCD makes itself apparent.

I like to operate in only very few files at a time, often closing loads of files when I take over the driving seat. Whereas Arun can often be found erasing trailing white space from the ends of lines and the bottom of files and lining stuff up in the code (he has apparently been drilled into this by working at wego with Chu Yeow).

Us developers are curious beings.

Weekly Stats 8 new features added with a current total of 76 scenarios. 652 lines of code and 1748 lines of test code with a code-to-test ratio of 1:2.7.

Simple daily git workflow

I've been looking for an everyday guide to git for a simpleton. The git simpleton in question is me.

One of the key things that Arun has brought  to my programming is the rigor of working in a multi-developer environment, an area in which my experience is weak. I've worked in larger groups as a designer, but it's possible to sit outside the flow of development lifecycle and drop HTML templates into the process.

However even I understand the importance of version control, and the emergence of git as the source control of choice (and the all marvelous github) mean I have been using git but only in a cack-handed way. What I was missing was the regular day-to-day repeatable how. If you're familiar with source control, this is not going to be big news, but I want to capture this as I'm still learning as its only really this week I feel I 'get it'. So here it is, I've even created a cheatsheet, which you can download at the end of the article.

There's load of ways to install git (standard setup article is under construction) so whether you want to install from source or download an installer, knock yourself out.

Simple Daily Git Workflow Once you've set up your repository on Github (go ahead a buy a nice plan while you're there) this is process we're following for every line of code we right:

Before you do anything make sure you're up to date with all the changes made on the remote master branch by other developers.

git checkout master git pull We like to make a branch for every issue/bug/feature we're trying to build so we start a new branch for each, this gives us the ability to always have deployable code in the master branch. We can also abandon branches where we've gone wrong and always head back to master, like insurance!

git checkout -b your-branch-name-here This creates a new branch for you to start making you changes and switches you into it.

Do your work here! The key thing to remember at this stage is to commit often, *really often* the smaller your commits the more you can undo any damage or later go back and see what you did. Whether its a change of layout of a single template or a single test passing commit it separately.

git status This shows you the files that have changed.

git add . This adds any new files you have created. You can add a series of specific individual files if you like, simply replace the dot e.g. 'git add your/filename/here'

git diff This shows the differences line by line. You could use GitX if you're on a Mac to deliver a lovelier graphical representation 'git diff | gitx'.

git commit -m "detailed message here" Commits your changes with a nice little informative message as to the changes you've made. At this stage if you feature/bug/issue isn't completed simply loop back up and do another small chunk of work!

Once your feature is complete or your bug is squashed it's time to bring the master branch up to date.

git checkout master git merge your-branch-name-here For your next feature or bug just create another new branch. For us we're linking all our branches to github issues, as Arun mentioned. So our branch names are all called issue-n to match up with that.

When you want to resynchronise with github.

git push Job done. For those of you who've made it this far you might be keen to download a pretty cheatsheet I've put together. I have pinned it behind my own monitor, lest I forget.

The Way We Work - Week 1 at Gameplan

As Andy mentioned last week, April 1 was the day the creation of Gameplan stepped into gear. We spent the morning setting up Andy's trusted ol' Mac Mini as the development machine (complete with Homebrew, Git, Rails 2.3.5 and other Rubygems); talked about the features we'd like to implement for the coming week; added them as GitHub issues; and away we went. There is a more detailed blog-post coming on the setup of our development machine - watch this space.

A week later, we'd completed all the features that we had planned for (and a few bonus ones as well) and it looks like we are on our way to meeting our first deadline.

A closer look at the way we work Andy and I decided that we'd like to have a four-and-a-half-day work week with Friday afternoons being spent doing planning for the next week, catching up on news, discussing interesting new ideas and completing any other crufty admin work we've been putting off. (Obviously a big part of yesterday afternoon was catching up with the iPhone OS 4.0 keynote).

Our planning sessions are generally quite quick (at least for now) - we don't try to dispirit (or kid) ourselves by planning too far ahead, but just enough for the next week.

GitHub Issues Once we've decided on the features, they get added as issues on GitHub. We decided to go with GitHub Issues as our project-management/issue-tracking tool of choice, since it is very simple, allows us to tag issues with multiple tags and ties in very closely with GitHub. For a two-member development team, we feel it's important not to complicate things with project management, but still have an efficient way of keeping track of our todos, bugs and features. GitHub Issues fits the bill perfectly.

Git Practices Each issue on GitHub gets its own branch - the rule that we'd like to enforce at Gameplan is that the master branch is always clean, i.e. all tests always pass on master. If a feature is a work in progress (and thus causes tests to fail), then it must be on its own branch. Once we've completed a feature and made sure that all tests pass, it gets merged into master and then pushed to GitHub.

Just-In-Time Development A great practice that we've gotten into (and one which I wasn't too familiar with) is just-in-time building with pair-programming. I'm sure BDD-gurus would scoff at my excitement at this 'new fangled' practice, but to practice it with discipline gives us great pleasure and confidence in our code. For the un-initiated, it goes like this:

• We start off by describing our feature using Cucumber. This clarifies our intentions regarding the feature, including things like what needs to be shown on the page, what are the possible errors that can happen on the page and where the user goes to after completing an action on the page.
• We then start writing functional tests for the controller in question and make sure that the controller does everything that is supposed to, including setting the right instance variables, setting (or not setting) the flash and handle any redirects if necessary. [NB: Cucumber comes built-in with RSpec, but we've decided to go with regular Rails tests sprinkled with Shoulda awesomeness]
• If the controller interacts with any models (well, if it doesn't you're violating the fat model, skinny controller pattern), we write unit tests to make sure that the models have the right behavior. If we are starting off with a blank state, this is when we define what goes in the model (and sometimes actually even create the model).

We definitely don't want to come off as having invented this method of development, but as a first-time serious practitioner of this methodology, I've come to realise the true power of behavior-driven-just-in-time development. Particularly when you're starting from scratch and it is easy to get overawed by the tasks at hand, writing Cucumber features and getting functional/unit tests to pass one at a time focuses the mind, and guarantees quality code as well.

The other interesting side-effect of this is that not once have we opened a browser to interact with our application.

So, where are we? It was a little tough for me to get used to the rigor of practicing behavior-driven-development (it helped that Andy's BDD-fu is pretty awesome), but once we got used to it, we started cranking out features at a pretty impressive rate, and at the end of week 1, our results look like this:

10 features completed, 31 issues closed, 337 lines of code, 696 lines of test code with a code-to-test ratio of 1:2.1

Singapore is nice, but it's not enough

I watched Sneha's e27 interview with Adeo Ressi, and one of the things he said troubled me. Like it troubled me before.

"Any startup that is outside the US and not in a large market... faces the challenge of too narrow a focus. We met some Singapore companies that are focussing on Singapore and that is a very small market." Adeo Ressi, thefunded.com.

Singapore is a good place to live, it has it's faults but where doesn't? It's basically clean, efficient and the sun mainly shines. And the food is amazing. Plus as a place to travel to and from it's pretty much unbeatable.

The lifestyle, plus friends, plus a feeling that the web industry is on the verge of something and good local developers are all the reasons I stayed here and teamed up with Arun to start building the best sports league software ever (take that link Google-bot).

However it is not a place to solely focus your (internet) business on. You're never going to make everybody use your product, only a small percentage. You are not Google or Facebook. A small percentage of only 4 million people (that's 0.07% of the world's population) is a huge mistake, however much you think you can sell to the local market.

You only have to look at all the adverts on the various SPH websites, for other SPH websites, to see that a Singapore-focussed 'eyeballs' business is a super-no-go. The same for inSing.com, a corporate news portal that's subsidised by phone bills and government advertising.

You certainly shouldn't market yourself as proudly Singaporean for Singapore. Be proud but take it out to the world - be the great advert for Singapore that the F1 is. Insularity is the long slow road to defeat.

Use Singapore as a fantastic springboard to virtually anywhere in the world. It's English speaking, with strong ties to local neighbours, plus China & India. It's basically got access to the biggest markets possible. Aim at them.

--

As for the rest of the interview... I was also a bit surprised that he widened the question of what he thinks of Singapore's startup scene into immediately talking about Paris. I think he may have been seduced by the Eiffel Tower. :-)

The first deadline

Wednesday Arun finished at Wego. So yesterday was day one.

We've decided, with a little pushing (well a long and detailed note from Sneha), that we should exhibit at e27's echelon event on June 1st & 2nd.

Initially we were against the idea, realising somewhat that a room full of geeks may not necessarily be our core market for a sports league website. However despite our misgivings the opportunity to put ourselves in front of 600-odd people and get their feedback seems too good to miss. This is particularly true given I get free admission having put together the logo concept for the event!

So that gives us eight weeks and one day to have something to show. Which is a nice tight deadline to motivate us, as if we needed it, although as Shannon put it last night at WebSG, "alpha in four weeks, beta in eight, easy".

With our tight deadline in mind we took today to plan at our work schedule for the next few weeks, what some might call the minimum viable product, but I'm going to think of as something we're not embarrassed to show people. Of course we're only realistically planning for the next week or so: planning is guessing after all.

After a couple of hours discussion, we did some interface sketching and planning and then got stuck straight into building. There's definitely a few articles that will come out of our work style, equipment and process but let's just say that we were making quicker progress than we thought and were also enjoying ourselves!

So the adventure begins here, appropriately enough, on April Fool's Day.