Naked Startup

So What Now?

It's been a while.

I think we can safely say that in its current incarnation Gameplan will not make us millionaires. Or frankly pay our salaries. However, this does not mean we are giving up.

Today's News seems to be a fantastic product and we have a hard core of several thousand readers using our app every day. Plus we have an iPhone version in the works, which should increase our users count several-fold. Arun even thinks it might be his preferred version.

But our (meagre) salaries have to be paid. So in an effort to do some interesting work and make some cash we met with several people over the last month or so to attempt to secure some paid work so we can fund ourselves as an entity for the forthcoming year.

After meeting with several potential clients we finally agreed to work with ViiKii on an extended consulting job that'll see us well into 2011.

What made us take the assignment? We're working on something that's an interesting project, with a decent shot at success, working with a talented team of staff and Pivots. Hardly a bad way to spend your life for a couple of months.

What should be noted at this stage is that we're not giving up on our 'startup', we're just going about it another way. We're both talented developers and don't need to spend other people's money on a workforce to build our ideas. We can help other people with their ideas, get involved, learn and at the same time fund ourselves for another run at Gameplan (or maybe something else) next year.

As is often said, investors are often backing a team rather than an idea, per se. We're doing the same. Investing in a team, but we're just funding it a different way; through our own skills. We back ourselves to do something amazing but by taking on interesting consulting work, for a little while, we don't need it to be right this minute.

Also the benefits of working with other people on interesting projects can only help us to avoid pitfalls and spark interesting new directions for us as a team. Plus it's nice to get out and about in a coding sense once in a while!

Software for Startups - FreeAgent

This is the first in a series of articles describing the support system of products we swear by at Gameplan. If a product is in this series, we can vouch for its awesomeness. I spent much of last year running a solo web-design firm, with some help and co-operation from another couple of local designers.

One of the things that used to be a massive hassle was cashflow: estimating, invoicing and tracking what money was coming in and out. I started out manually creating and tracking sent invoices and estimates, but this was a massive 'extra headache' - who was I waiting on for approval or payment and what was I spending?

As a side note I even hand created templates thinking that a designer should have 'nice looking invoices', which was a big waste of time - don't do this, put your logo on a simple invoice and send it out. Invoices are for getting paid not proving how talented you are, save your creative effort for the project at hand!

I dabbled with a couple of 'on laptop' systems but was concerned about the single point of failure, plus the various solutions didn't seem to capture the 'what am I spending' part of my financial story.

Enter FreeAgent.

FreeAgent literally saved hours of time and headaches. It deals with the invoicing and estimating process and time recording in a straightforward way. In addition you also get useful graphs and charting of your business incomings and outgoings.

The most useful thing was tracking my outstanding invoices when running multiple concurrent projects, When you import your bank statements the invoices and payments are all automatically synced and marked as paid. This year they even added automatic reminders so the system can remind clients for you. Brilliant.

Being UK-based they interface well with the downloadable formats from the UK banks, but I emailed them a sample of DBS's awful CSV download and they added compatibility. That's what I call service! And they've done it again for another Singapore person. And when you import your CSVs it remembers payees, so the more you use it the better it gets.

While the last few months has mainly seen money leaving the business (a trend we hope to reverse soon!) I've still used FreeAgent to track our spending and do a couple of estimates for consulting work. When we kick in with receiving payment via PayPal, FreeAgent will link up with that too and track our incoming funds - super-awesome.

For me FreeAgent is better than the competitors because it treads the line between too complex and too simple and ends up hitting the sweet spot of doing everything we need and then getting out of the way.

I've since eulogized FreeAgent to a couple of people and everyone I've referred has been extraordinarily happy with it. Plus they seem like a bloody good gang of people solving a problem, hopefully like we are, so supporting them makes me feel good.

Why not give FreeAgent a try? If you use any of the links in this article you'll get 10% off (and so do I) and there's a 30-day trial... so double win right?

Week 6 - Apart

An odd week just passed. I was in the UK and Arun was in Singapore. So, because of the differences in timezones and the fact we had some solo tasks to complete, we didn't pair.

I was mainly working on the admin interface to Gameplan, meaning this was the first time either of us had really spent any time 'clicking around' in the interface.

I've implemented a bare bones look and feel for now but a lot of my activity was spent establishing the multiple linking methods required to make the interface properly human-usable.

The oddest sensation (aside from 26 hours of long-haul flight for less than a week of trip) was that I didn't feel like I was making the progress that we've been making over the past few weeks.

I suspect that this is only partially true. Design, as I practice it, tends to iterate on the same things many times, each version better than the last. Plus the final result is a long way from the 'bare' pages we created as part of our feature development stories.

Arun's been working on a nascent importer for data which will be a requirement both for moving users onto the system and for having a demo-able system in the coming weeks.

No stats this week, although I have written some tests: I had to create methods on the models and adjust features to look for changes I made to the wording of the interface. This week should be more 'feature-tastic' as we return to working together.

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.

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