Documenting a Startup Episode 3

After uploading the version 1 How Do You Feel app, and feeling pretty good about it (no pun intended) I decided to do some work (just an hour or two here and there after work) to pretty it up a bit. I can’t have something horrible floating around on the web with my name on it surely? It looks like this personal experiment (continuous integration) is actually working, as even the smallest changes are pretty rewarding to see on the live URL, making me more motivated to keep making them instead of just reading Hacker News or learning some wanky programming language I’ll probably never use until bed time.


Version 1 – The debut

The concept here is that there’s a simple question, how are you feeling today?

There are two axis you can vote along and no words, just pictures. Right to left is happiness, up and down is exitement. So you can be happy and exited (overbearingly happy), happy and unexited (content), or unhappy but neutrally exited (simple depression), or some combination (there’s 9 total).

Clicking on an element takes you to the next screen which says which one you chose, and then goes and gets the aggregate happiness for the entire site, so it immediately gives a sense that you’re connected to something bigger.

The whole idea is that it’s about the user. How do you feel? And it’s such a subjective question that you’re compelled to answer it, knowing that there is no wrong answer. The phrase how do you feel was determined by using the Google Keyword Tool, which scored high on traffic and low on competition.

The foundation for the app is GWT and it’s written in Java. Some people say Java is too verbose but I’m a fast typist (again, no pun intended!) and I absolutely love the way Eclipse can check and auto complete code as you type. Sure Python might be faster and it interrupts your mental flow a bit less by not getting in the way as much, but it’s pretty damn cool to be able to code the same language throughout the entire application stack.

On the backend I’ve used the appengine datastore and Objectify. The datastore is treated pretty much like a giant hashmap. You just take an object, pass it from client to server (all transport is abstracted away once the interfaces are defined), then objectify.push(object) it straight into the datastore, love it. I do quite like relational databases (more than NoSQL) for the record, but the idea of mass scalability and the novelty of not having to write queries to get or store data (speeding up development) seemed intriguing enough to at least try the datastore out for this app.

Version 2

The site gets a little more complicated with the addition of geolocation code. It checks your IP and uses a free API to get the city the user is from (url: Some testing though proved it to be not quite accurate enough. It worked well on my computer, but using my phone it said I was in Sydney instead of Melbourne. The description of the API said it accepts user submissions of location based on blocks of IPs, so I’m guessing the company my phone is with (Optus) is assigned to Sydney, even though they use some of their available IPs in Melbourne. Either that or I’ve heard that mobile networks sometimes NAT the entire network, so maybe all phone’s appear as the same or at least a very small set of IPs to any external website, making the per city functionality useless for mobile devices.

The other option was to use HTML5 geolocation, but the problem with that is it asks the user to confirm they want to share their location. We don’t want the users exact position down to the metre and asking for permissions disrupts the flow of the user experience. Instead I kept the API but changed the app to get location by country. Broad enough that no personal information is requested but precise enough to be useful and accurate.

Version 3

The most immediate change is that we’ve simplified. Rather than having two axis of happiness, a concept that itself needs to be explained, there are just three faces to choose from. Your country is automatically selected for you, and a map of how the world is going is displayed right away.

Between version’s 2 and 3 I also read the book The Lean Startup by Eric Ries, which was a real eye opener into the management principles you’ll need to survive in the modern world. His basic premise is that scientific management, pioneered by Frederick Taylor in 1910 has been taken too far, and used as an excuse to make the workplace too rigid and unable to change. This is probably because the companies at the top of the food chain want to maintain the status quo and just stay profitable forever (and who wouldn’t want that), but the world is changing. Disruption is the new buzzword and the rate of change is never going to decrease. The lean manufacturing movement was pioneered by Toyota decades ago to somewhat counter the trend towards inflexibility and waste, and Eric Ries takes the ideas into the world of software where they thrive as useful tools to turn today’s behemoths into tomorrows agile (but still large) organisations.

I’ve started applying it to this experimental startup by thinking of every change not as a feature to be implemented, but as a hypothesis to be tested. In thinking lean we want to minimise waste, and there’s no greater waste than working diligently to a plan that was wrong to begin with. Every plan makes assumptions and leaps of faith, so the idea is to make changes as small as possible and to test them with real data as quickly as possible to tighten the feedback loop. Although it’s slightly more effort, Ries argues that it is far, far less wasteful than wasting valuable engineering hours on a perfectly flawed, unverified plan.

I’ve added a link to my pivotal tracker to the website, which is where I’ll store the hypothesis to be validated. There’s also a feedback link to capture any input from existing users.

Version 4

After watching a user struggle to use the website I made a few basic changes, and it’s clear that there will be many more required in the future. What’s the deal with the colours, how do they relate to the faces? So I’ve added a colour gradient beneath the faces and given them words, so a user knows exactly what they’re getting when they click it. The colours also relate to the map, yellow is happy, blue is sad, and green is somewhere in the middle according to the gradient.

And how are we going with validating hypothesis? Well, the overall hypothesis of ‘I think people will want to see how the world is feeling’ is not yet proven positive, because there’s been almost no visitors. To be fair, no one knows about the site except the facebook visitors, and they got version 1, so you wouldn’t exactly expect them to return.

To be even fairer, the site does need more to it. For a start, you can click a face as many times as you like and they all count as valid votes. Who can trust the data when that’s the case? So if I was being true to the method, I’d have to say that we’re not actually to the ‘testing’ part, we’re still in implementation.

I’m currently reading a book on design called The Non-Designers Design Book which is proving to be full of the most immediately useful design ideas around (the low hanging fruit), perfect. Maybe it’s time I had a look at the site from the design point of view before coming back to implementing a single vote mechanism.

The best way to validate one vote per user per day would be through a login method, but I think that forcing users to login at this stage would interfere with any testing activities. I’ve only had a couple of visitors do this, but even coming to the site and spamming votes shows there’s some interest. Ideally it would support Google, Facebook and Twitter login, and I could easily do Google login, but what’s the point of doing any login system if the idea itself is fundamentally flawed? I’m quite prepared to pivot, and until the idea as a whole is validated as useful I don’t think it’s worth doing any long term engineering work, especially with such scarce hours (maybe 1 per day on a good week) to contribute to it and this blog series. So unless it becomes critical for testing, login will have to wait, hopefully I’ll have a better idea to validate the idea behind the site in the mean time.

Scale Fail
I also ran into my first engineering constraint with app engine. Every ‘vote’ is stored in the database as an individual record, and when getting the overall score for a country (done once per vote, and once per country every time the map is loaded) you have to extract every relevant record from the database.

If you vote ‘happy’ on Australia and it returns that there are currently 300 votes with an average score of ‘happy’, that’s 300 read operations it’s had to do to get that result. And every time you click vote, it does 301 more, 302 more, 303 more. The world map is even worse because it does every vote in the world for the last 24 hours. I had a user or two spam votes until the map just stopped showing up.

Logging into the AppEngine backend it showed that I had exhausted the daily quota for reads which is 50,000. This wouldn’t be a problem on a relational database as you could use an aggregate function to average it for you on the server and simply return the result. However, that’s the point of AppEngine, that would take up processing time on the database and that means as the app grows you’re going to need more database servers, which is pretty wasteful. So with AppEngine, you can’t do that.

What the answer needs to be is that for every vote it looks up the current score and updates the average, so the server only needs to pull the current average out for every hit. For the world score it can contain the average of each country as separate properties in one record, so getting all that data out is still only one ‘read’. I’ll setup a cron job to recalculate the averages from scratch every 15 minutes or so.

Looking forward to polishing off this iteration to see if it’s a winner or a dud that can be pivoted. Either way it’s just great to keep learning about GWT, AppEngine and lean startups.

Comments are closed.