How Real did I Get: Part 1, The Starting Line

This is the first in series of blogs I'll be doing reviewing the experience I had taking my getconnectedto.me site from an idea to launch. I'm reviewing this relative to the 37 Signal's "Getting Real" book (http://gettingreal.37signals.com) - a "bible" on "ship-it-above-all-else" software development mentality I've given many a sermon from.

I want to review just "How Real did I Get?" - did my experiences match their philosophy? Where did they differ? Why did they differ? What would I do different?

Today, I'm examining Chapter 2 (which is really the first chapter after the introduction) - "The Starting Line" (http://gettingreal.37signals.com/toc.php#ch02)

What's Your Problem

Build software for yourself

A great way to build software is to start out by solving your own problems. You'll be the target audience and you'll know what's important and what's not. That gives you a great head start on delivering a breakout product.

Getting Real, 37 Signals

One of my other bibles for "entrepreneur realism" is Guy Kawasaki's "The Art of the Start". It's worth the cost of the book for Chapter 1 alone and even then just read the section called "Making Meaning" (actually do it for free over here). Guy, a hardened Silicon Valley veteran of the startup and Venture-Capital industry, points out that startups need to be able to:

• Work long hours for low wages.

Check! I've gone without wages for 3 months to get this venture off the ground, using up my savings to pay the bills - with my wife being an at-home-mum, our family income fell to zero for this period. Ouch. Think of all the cool things I could have bought with that income (I think I am the only person I know of without a flatscreen TV).

• Deal with rejection after rejection.

I don't even bother waiting for the rejection anymore, I just assume it's out there waiting for me. Australian culture is even less forgiving of those that "go it alone" outside of the mainstream (see Tall Poppy Syndrome). I'm used to the blank looks of incredulity, and what I am sure are behind the back conversations about how mad I must be, from close friends let alone a wider business community. The rules in our society today seem to be "Work. Increase Income. Increase Debt. Work harder & longer. Increase Income. Increase Debt. Rinse, repeat".

• Can you handle the responsibility of dozens of employees?

Well, there is me. And me. Not so much of a problem when you are a one person startup, and a good reason in my opinion that every startup needs to be bootstrapped by 1-3 people that work long hours for free to get an initial product off the ground.

The bad news these days is you can kiss goodbye the change of large sums of VC money being thrown at you for your sketch on the back of a bar coaster. The good news is that you don't need it - provided you can be motivated to work hard for short periods of time for free. The main barrier to entry is skill and time - not upfront capital. I wrote about this the other month when starting out on this venture.

Kawasaki argues that the key to overcoming these motivational barriers is to "Make Meaning". "Making Money", whilst important in terms of your long term business strategy (especially once you get those "dozens of employees") is not as important in the short term as making sure you are motivated to "Make Meaning". One of his definitions of this is to "Right a wrong" which I believe aligns perfectly with the Getting Real mantra of "Build Software for Yourself".

With getconnectedto.me I found a need (a nice centralised locational for personalised online connection details) that wasn't satisfied by sites such as Plaxo and Xeesm.com (just what the hell is Social Network Relationship Management anyway??!). To me this was the Wrong I wanted Righted.

In Fred Brooke's landmark book "The Mythical Man Month" I remember coming across a description of programming being the closest thing we'll ever come to being "Magicians". Programmers literally create concrete living entities (applications) out of raw "thought-stuff". When you can program you are liberated to go create the application that meets your needs and put it out into the world.

The downside is you can't ever whinge about somebody else's website or software again. If you don't like it, pull your finger out and get cracking on building something better. You have to put your money where your mouth is as they say.

Fund Yourself

These days it doesn't take much to get rolling. Hardware is cheap and plenty of great infrastructure software is open source and free. And passion doesn't come with a price tag.

Getting Real, 37 Signals

As mentioned above, I wrote about this the other month. Hardware was better than cheap for me - it was free. By targeting the application to run on the Google App Engine - a Java and Python cloud platform for web applications, I could put a website up on virtualised scalable infrastructure for free. The App Engine did have a price model but it would scale with my traffic and for a few $ a month would handle a great deal of that before costing any serious cash.

My domain name cost $10. My private SVN hosting solution $100 per annum. Cable broadband internet connection around $80 per month. My main cost was my MacBook Pro laptop, purchased some 2 years ago (i.e. a sunk cost) via a salary sacrifice scheme for around $4,500. Two years on, the 4GB dual CPU laptop gave me all the power I needed.

Development was done on Eclipse (free), using Google AppEngine plug-in and libraries (free) and leveraging the multitude of excellent open-source Java libraries out in the world these days.

Fix Time and Budget, Flex Scope

Here's an easy way to launch on time and on budget: keep them fixed.

Getting Real, 37 Signals

My schedule was definitely fixed early on in November. My new job would start on the 18th of January and that formed my hard deadline. I was under no illusions that this job would consume a lot of my time and "mindshare" - I don't do jobs to kill time or earn money - you need to find meaning in a day job as well by doing something you can fully commit your energy and enthusiasm to.

Whilst I was working for "free" this still equated to a budget when you factor in opportunity cost. Every week was roughly around $11,000 pre-tax dollars I wasn't earning. If I was an employee that would be costing my employer even more once overheads are added on - let's say $15,000 a month to make the math easy. My budget for a 3 month project was therefore around $45,000.

Fixed time, fixed budget imposed by constrains of doing this venture between jobs. If the project ran over time/budget the outcome was starkly obvious to me - it would never go live. I would get absorbed into my new role and the yet to be launched site would gather dust in my backup archives for the rest of time.

If however I launched and got at least a few friends using it before January the 18th this could help me maintain the motivation required to dedicate hours outside of my main job to keep the site evolving.

The good news was last Sunday 10th of January I launched what I consider "Version 1" and now have a small handful of people using the site in anger. On time and on budget, but it wasn't easy....

Have an Enemy

Pick a fight

Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go.

Getting Real, 37 Signals

Anybody that has ever had an idea for a new venture will be familiar with this sequence of events. It goes something like this:

Entrepreneur: "Oh my god, I've got a great idea.". Spends 10 seconds on Google, concludes nobody else is doing anything like it (hello Confirmation Bias again). Starts frantically working away on it.

Entrepreneur: Shows early prototype to Friend #1.

Friend #1: "Wow, that is so cool - I'ld use/buy that"

Entrepreneur: Really motivated now, goes back and puts more work into fleshing out the prototype. Shows refined prototype to Friend #2.

Friend #2: "Umm, doesn't XYZ.com already do that? Oh and ABC.com I think have something similar"

Entrepreneur: "errr.... I'll be right back" - runs out of the room, fires up Google does a *proper search* finds that XYZ and ABC do indeed solve the same problem. Gives up.

I had a similar experience with getconnectedto.me - quickly being told about two competitors. One I knew of (Plaxo) - but whom my confirmation bias had ignored - and one I didn't know about (Xeesm.com).

One thing I've learnt over the years (both from experience and formally been taught in an MBA course) is that "Competition is Good". Competition is a sign of a valid market (i.e. "customers"). No competition means it is most likely you are building a product nobody will ever want (or No competition = no market = no customers = no money).

The Getting Real philosophy of building something you need yourself means it is almost 100% probable that there are, in a world of 6.6 billion people, existing people that have had the same or similar need and a subset of them will have done something about it (i.e. build a product or service and take it to market). So it's not the end of the world - it's just the way of the world.

Business schools (the good one's anyway) will tell you that a business model is not necessarily what your do differently to your competition. Often the most successful business models are those that define what you Don't Do relative to your competitors (I recommend reading anything and everything by Michael Porter on this).

Or as Get Real put's it so simply and elegantly "Sometimes the best way to know what your app should be is to know what it shouldn't be".

In this sense I agree complete with the "Pick an Enemy" philosophy. When Friend #2 inevitably points out an overlooked competitor, don't get disillusioned - get mad. Get angry even. Take it personally.

Go to their website, use their product. Get emotional about the way the deliver on "Your Need". What baggage do they throw in you don't need.

For me it was simple. Plaxo was trying to own the social relationship - it was trying to be a social network in itself. Good for them. I didn't need another social network. I needed a "Social Network Hub" - a jumping off point for my contacts to connect to me on other networks.

For Xeesm.com, I didn't need any of the "Social Network Relationship" baggage that came with it. Secondly the ".com" domain just didn't quite scratch my itch. If I wanted to put a URL on my business card I don't want somebody else's ".com" domain on it - it just confuses things.

By focusing on my "enemies" I was able to make some really good decisions about what my site wouldn't be. By not being a social network in itself and not owning the social relationship I could divorce myself for a whole swag of user / contact management features that don't address my core need.

It Shouldn't be a Chore

If your app doesn't excite you, something's wrong.

Getting Real, 37 Signals

My theory is that in any company larger than, say 1 person, there will be arguments about what technology to implement the idea in. The length and degree of emotional conflict of these arguments will grow exponentially with the size of the organisation.

One advantage of a small (3 or less people) startup is you can pick technology that REALLY motivates you. For me it was Java plus Google App Engine plus Mootools AJAX libraries.

For many other's I'm sure it would be a .NET technology, or a LAMP stack, or Ruby on Rails.

One good friend of mine would be in geek nirvana if his startup involved programming in Erlang.

As the saying goes, "what ever rocks your boat".

I don't believe technology is that important (a heresy to many people I know). It's a means to an end. If the technology doesn't do X, that's ok you can build X out of what it does do. There is no uber-language for a website. Technology choices are just an exercise in tradeoffs.

What is important is excitement. Excitement get's you motivated, get's you into a state of what psychologists call "Flow". In my experience 8 hours of programming in a "Flow" state is equivalent to a week or more of working in technology you dislike.

Phew! - that's it for today's retrospective on my Getting Real experiences. Tomorrow I'll be looking at Chapter 3 - Stay Lean.

Hope you are enjoying this series. Feedback on my or your own experiences is most welcome.

How Real did I Get? The journey from idea to going live.

Yesterday I did something that made me incredibly nervous. I went live with my startup venture getconnectedto.me.

By live I mean I invited a couple of close friends to sign-up and create their own profile page. The site itself had been "live" since November but in a basic "read-only" fashion. Yesterday was the culmination of 3 months work to get it to a state where users could sign-up and start generating their own site content.

I didn't think I would be quite so nervous. But having sent the invite emails I found I had to leave the house and take a drive up into the mountains as a distraction from waiting for the what I was sure would be the inevitable "it didn't work for me" replies.

Today I caught up with one of those users. He reported that in under two minutes he had successfully created his own profile page and was very impressed. I let out a big sigh of relief and briefly, just briefly, started to feel smug.

I had done it. I had taken an idea, distilled it's essence to a core goal and delivered on it. I had done this in under 3 months and I now had a executable product I could start promoting. It doesn't sound like much, but having started numerous "startup projects" over the years and, prior to yesterday, only having delivered on one of them it was a significant milestone.

Ideas are the easy bit. Everybody is an entrepreneur these days - every city is awash with "Entrepreneur Clubs" and "Startup Schools". The hard bit is actually going live with an executed version of your idea.

My idea for GetConnected was not even the idea I thought I would be implementing. Last year I engineered a 3 month "sabbatical" gap between jobs that I was going to put to use to execute on a startup idea I had around collecting online news & editorial.

As I was going through the process of leaving my old job I was struck with the though of how many communication mediums I had for my colleagues and friends I had made at this job to "stay connected with me". There was LinkedIn, there was this blog, there was Twitter, email, Facebook, Skype etc. etc. Each serving a different purpose but each a social connection medium I utilised. Additionally there would be other social networks I would inevitably use in the future. How would people know where and how connect with me then (for instance I've since jumped into Foursquare)? Rather than give out a laundry list of connections that could quickly become out of date, I wanted to give out a simple single URL that centralised all this.

I jumped onto GoDaddy and quickly found myself some useful domain names that scratched this itch I had found. "getconnectedto.me" was my favourite and the one I used to create my profile page to give out to people as I left my job. Instead of the above laundry list, I simply gave out:

http://getconnectedto.me/ashley.herring

This scratched my itch, but I soon found a lot of others in my network that had the same itch and soon started asking for their own profile pages. All of a sudden I had a simple product idea with appeal that I could execute on. All I needed to do was write a way for people to edit their own profile and I was off and running. Rather than work on my news and editorial collation/crawler project I would first get this idea executed and live. Surely it couldn't take that long - functionally it was so simple after all.

What initially seemed like it would be at most a 3 week project took me close on 3 months duration. Admittedly it wasn't 100% time spent on this project - I had another boss, my Wife and our landscaping projects to answer too, but it did give me an appreciation of how even very simple ideas take a huge amount of effort to properly execute and "go live" with.

To mark this milestone of having executed my idea I decided to reread 37 Signal's "Getting Real" (http://gettingreal.37signals.com). When I first read this manual about quick (I refuse to use the now overloaded term "Agile" - more on this later), "going live" focused software development philosophy, it struck me as a manual of "things I already intuitively knew and did anyway", but I was also aware there was probably a healthy dose of Confirmation Bias at work here. It's easy to "talk the talk" but could I "walk the walk"? How "real" was my very own "Getting Real" experience?

Over the next week I'll be blogging about my honest warts-n-all experiences at building getconnectedto.me in relation to the Getting Real book - what worked for me, what didn't and where I could have improved.

Tomorrow - my experiences in relation to Getting Real, Chapter 2 - "The Starting Line".

The Curious Case of The Y2.01K Bug

I love a good computer bug story.

The 1st of January, 2010 saw a real doozy come to light: The Curious Case of the Bank of Queensland "Y2.01K" Bug.

The Age published an article on it over here. Bank of Queensland customers were surprised to find their transactions failing to clear on the 1st of January 2010. It seems the Bank's systems believed the current date was the 1st of January 2016 not the 1st of January 2010. Credit card transactions were naturally being rejected as expired - correct behaviour for a system that thought it was operating 6 years into the future.

It's easy to laugh and point the figure at poor programming, but date related bugs can be very innocuous - tricky little time bombs, ticking away, waiting for the right temporal conditions to blow up and bring down your system. I know, because I've been bitten by them before. My first job was working for a company that supplied Airport operational systems and I had the pleasure of missing the first half of Les Misérables one Sunday afternoon as I was called into fix a system I had created that had failed to correctly adjust local time for Day-Light-Savings. Like most bugs it turned out to be a single mistype of the keyboard - a plus where I should have used a minus in a block of date logic, but it gave me an appreciation of how systems that go through very extensive testing (at the developer/consultant side and at the acceptance/client side) can miss these bugs.

So back to BoQ and their Y2.01K bug. What the hell went wrong? How can the year go from 2009 to 2016. Are the programmers just seriously incompetent or what? Well, without knowing the codebase or the system I think we can make some educated guesses.

First off, is it likely somebody mistyped something like:

year = year + 7 instead of year = year + 1 ?

This would be an interesting bug because depending on the type of font used in a code-review, it could be a bug that passed a peer code review session. 7's and 1's can look very similar in many fonts.

This is unlikely as it would manifest itself at the first New Years a system is operational. I'm suspecting this system has been around for a lot longer - just by the fact it has taken many days to fix (I'm still not sure if it is even fixed). This is probably a system that is several years old and the original developers are being tracked down to help debug.

So, not a simple mistype - then what. How does a system jump forward 7 years instead of 1? Why is it doing date incrementing logic anyway instead of just using the system provided date?

I think the clue to this lies in the year it jumped to: "2016". That's a very suspicious year. Particularly the "16" bit. You see, in Hexadecimal (Base 16 - a more workable mathematical modelling of the binary numbering system computers are based on), the value "10" is equivalent to decimal "16".

Hexadecimal counting goes 1,2,3,4,5,6,7,8,9 then A,B,C,D,E,F before rolling over to "10" which is the 16th number in the sequence.

To repeat: that is "10" Hexadecimal = "16" Decimal. What happened at BoQ? It went from 2009 to 2016 instead of 2010.

Ahhh... I suspect this might be a highly plausible candidate for the bug. I'm assuming the system has somewhere in it's bowls a "current year" field. I would further assume that it doesn't store the century just the year as an offset from the year 2000. Hence 2009 would be stored as "9".

Here's a theory. Whatever system routine is called to get and set the value of this date takes and receives a Hexadecimal value. Perhaps it's a real low level routine, getting close to the bits and bytes of the computer rather than dealing in unnatural (to a computer) decimal base numbers.

Let's say there is some pseudocode logic in the system that goes like this:

boqSystemYear = getBoqSystemYear()

currentYear = getOperatingSystemDate().extractYear()

if currentYear > boqSystemYear then setBoqSystemYear(currentYear)

The operating system function returns the year as a decimal value, which on the 1st of January 2010 would come back as "10".

The low level BoQ system year, if we assume works on hexadecimal, would currently set to "9" (which is the same in both hexadecimal and decimal). The code picks up that it needs to be updated to decimal "10" but forgets (or is unaware) to convert it to hexadecimal (10 decimal = A hexadecimal). Instead it sets it to "10" hexadecimal which is 16 decimal.

BOOOOOOOOOOOOOOOM!!! The ticking time bomb goes off. The system now think's it is 2016 instead of 2010 and chaos ensures.

Here we have a hypothesis that fits the observed facts. Without knowing the codebase we can do no more, but it does highlight how these innocuous temporal bugs can occur. Is this the result of sloppy coding? Hard to say. No programmer or even team of programmer works completely in isolation building a system from the lowest levels up. They work on top of layers of code created over many decades by thousands of other programmers. Layers that provide operating systems, database systems, date & time manipulation routines and so on. It could be that this hexadecimal/decimal bug is the result of poorly documented routines that did not advertise what they expect their input in or provide output as. Mind you, this usually this occurs when numbers are transfered around the place as strings, which is a bit of an "anti-pattern" in itself because of these sorts of bugs.

I'm not a tester, but I wonder how many systems go through a range of what I would call "Temporal Testing" - testing the system at particular points in time. From my experience the focus tends to be on functional test plans and meeting performance KPIs but not so much on rolling the system through a range of dates. Note that this is different from putting in a range of date data into the system - this involves moving the system clock forward in time to test how the system behaves operationally in the future. It would be easy to identify a range of boundary dates to simulate future behaviour on - New Year Change-overs, Day-Light-Savings, Leap Years, Month end/start dates (check all those 30/31 day months are correctly done).

Any others? Are there test systems / test beds out there that do this sort of temporal range testing?