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?

Startup 1-2-3.0

The evolution of the IT Startup, 1999-2009.

Startup 1.0 - “Splash The Cash”

As the Dot Com Boom got underway in the late 90s one of the star performers of the period was Sun Microsystems. It seemed every garage startup and every funky web outfit wanted to be kitted out with Sun hardware. Server rooms were filled with farms of E10Ks. Any serious developer worth their salt required a Sparc Workstation with a 21” monitor to get any work done. All of which were running Solaris operating systems of course. Sun's stock price peaked at $241 USD in 2000 at the height of the Dot Com Boom.

That was just the hardware and OS stack. The application stack was just as (if not more) expensive. A plethora of new “Dot Com” IDE products were brought out by the established development tool vendors such as Borland's JBuilder. Version control was managed by Rational's Clearcase product and RDMS' would be Oracle systems. Not only were these tools pricey - at one stage I remember the Dot Com I was working for being quoted $100k to “upgrade” their Clearcase License to support multiple geographic locations - but also often required full-time administrators.

These “Startup 1.0” ventures could burn through a million dollars pretty quickly, even for a small outfit. The fixed costs in setting up were significant (a Server room, all those E10Ks running Solaris, Rational tools, Oracle servers and full-time admins) and so too were the marginal costs per developer, i.e. a Sparc Workstation with 21” Monitor, IDE license, plus often a second Windows workstation for mainstream applications such as Office and Mail (Perhaps not coincidently VMWare was born during this period).

Sure there existed cheaper alternatives to the above stack, but the funny thing was companies that wanted to attract the top talent felt they had to have the top infrastructure for them to play with. The price of this startup infrastructure tended not to be an issue – after all that's why they needed that initial round of $5M venture capital investment upfront before they could get started coding.

Having worked through this period for a couple of Dot Com's, I'm still not entirely sure what came first in this Chicken and Egg conundrum: Did startups require large initial rounds of VC funding because of the high infrastructure costs or were the infrastructure costs high because VC funding was readily available in large amounts in the late 90s?

Startup 2.0 - “FOSS DIY”

The Dot Com Bust well and truly burnt the investment community. Investment capital was all but non-existent for IT startups.

Entrepreneurs being Entrepreneurs however, kept on inventing and dreaming up brave new frontiers of the web. During this period (most of the 2000s) the Web 2.0 world slowly took shape as startup ventures like MySpace, Facebook and LinkedIn rose from the ashes.

For many of us involved in startups during this period it can be summarised by one word: Bootstrapping. Without large amounts of upfront investment available on the basis of a hastily contrived business plans and power point decks we were on our own. Now it was the founders own money (as either hard cash or opportunity cost through forgone earnings) going into starting the business resulting in a real focus on cost reduction and savings. Spending your own money is no where near as much fun as spending other people's.

Into this “investment vacuum” entered a rapidly maturing Free Open-Source Software (FOSS) industry. Whilst FOSS had been around for decades, I believe it was this post dot-com period of bootstrapping startups that really helped bring it to maturity.

Unlike the big capital investments of the Startup 1.0 days, with FOSS we could now get a “Startup 2.0” running for next to nix capital investment. Readily available Linux distributions ran on commodity PC hardware not high end rack mount servers. The rise of AMD to counter Intel's dominance in the PC market helped drive the commoditisation of this market. Unlike the Startup 1.0 days Sun hardware was now mainly the realm of the Enterprise customer and was coming under increased attack from IBM and an up-and-coming precocious company called Dell.

Startup 2.0 web servers were hosted by the free Apache HTTP Server and Tomcat Java Application Servers. Postfix ran our mail. Bugzilla managed our projects and Subversion kept track of our code repositories. Open-Office, a FOSS Sun Star-Office spin-off, created and managed our documents, Thunderbird provided our mail client and Mozilla (which would later evolve into Firefox) browsed the web for us.

Importantly, internet connectivity was becoming both cheaper and and bandwidths getting bigger. We no longer had to go purchase software packages physically from a store. We downloaded it for free over FTP from the closest mirror site.

Startups could be bootstrapped very cheaply. The main outlay was in servers. No longer rack mount Sun Sparc servers, it was now dirt cheap PCs, often self-assembled, that ran Linux. For under $10K you could get 2 or 3 decent servers up and running.

A developer “workstation” was now a sub $1,000 PC, also running Linux. The rise of FOSS IDEs such as Eclipse meant that there existed a serious free alternative to the expensive enterprise IDEs leftover from the Startup 1.0 days.

Whilst Startup 2.0 required very little cash in terms of fixed or marginal costs, what it did require was skills and time – the Do-It-Yourself (DIY) part of the deal. FOSS software needed to be downloaded, installed, configured and managed. Many IT startups at this stage contained through necessity an initial team with a hybrid of web designer, programmer and Linux sys admin skills. Cash was sparse but what we could freely invest was our time and skills.

The problem was that ever hour spent setting up a FOSS stack and administering it was an hour less time your could spend building whatever product or service your startup was meant to be offering to the world.

Startup 3.0 - “In The Cloud”

A couple of weeks back I started up a new venture – getconnectedto.me a “social network hub” to centralise online contact details. I discovered that there has never been as easy or cheap a time to start a new IT venture.

For $50 per annum I created a single user account on Google Apps to host email (and other services) for this domain. Google Apps allows me to use Google AppEngine to host my site. Google AppEngine comes with generous free quotas so until my site becomes (hopefully) busy enough to switch over to billed resource usage. Like the Amazon EC3 platform, it provides a zero fixed cost and negligible marginal cost deployment platform. You can get a hell of a lot of CPU cycles and page hits for the $10,000 or so you would have spent on commodity hardware in the Startup 2.0 bootstrapping days.

What really hit home to me was that in this “Startup 3.0” phase an Entrepreneur should always evaluate what infrastructure can be outsourced to a cloud hosted Software-As-A-Service style offering. What was a interesting to me was that the answer is “pretty much everything”.

A case in point was when I started to setup a Subversion repository for my project. As this is currently a single person venture I mainly wanted Subversion for version control rather than for team code management. My initial thought was to just set up Subversion Server on my MacBook which was backed up wirelessly to the Time Capsule in the house. Having done this before, I was confident that it should take no more than 30 minutes to set up using Macports, a Linux style OSS package manager for the OS-X operating system.

Several hours later I realised I had gone down a rather deep rabbit hole. For those interested in the rabbit hole details, see below, otherwise skip ahead...

Having recently upgraded to Snow Leopard I found that Macports was now broken. I went and installed the Xcode optional package for Snow Leopard and was able at least get Macports operational. The next problem I found was that standard port packages such as Apache Server suddenly would no longer compile. After much research (a fancy word for “googling”) I eventually bit the bullet and decided to wipe away my existing Macports installation and restart from scratch. Success – Apache installed ok. I then found more compile errors when installed Subversion server – errors in it's dependent components. More Googling, err I mean “researching” led me to a forum fix that involved hacking the Macports configuration files.

At this point I woke up and decided enough was enough. What the hell was I doing? I am meant to be creating a “social networking hub” website, not spending most of a productive day stuffing around with Macport configuration files.

Five minutes of googling and I had found and selected an online Subversion repository service called CodeSpaces. For $3 per month I could have a basic private repository with ample backed up storage for my projects.

Let's just stop and go over that last sentence again, in particular this bit - “$3 per month”.

That is just ridiculous. That is so cheap it is as good as free to me. Let's say it would have taken me 2 days to setup Subversion Server on Macports and assume 1 day every 12 months worth of administration overhead to manage (upgrade, backup etc.). To keep the math trivial I'll say the opportunity cost of my time is $1,000 per day. In the first year the opportunity cost of setting up Subversion myself locally would be $3,000. Versus $36 for a hosted Subversion offering – and that includes backup.

The penny dropped. Startup 2.0 – FOSS DIY is dead. Time is money. Spend time making something new and valuable to your customers. Stop spending time on setting up infrastructure for your startup venture. Outsource absolutely everything you can to a cloud service.

The Startup 3.0 office is an internet connection and a laptop. If I could move my IDE into the cloud I wouldn't even need that high spec a laptop. Guess what? Last month Microsoft announced it was working on creating a Cloud based version of Visual Studio. Once the Eclipse Foundation teams up with a Cloud provider and creates a cloud based Eclipse service I'll go order a basic MacBook Air laptop and sell off my high end MacBook Pro on Ebay.

The Rise of the Microstarts

So, welcome to the brave new world of Startup 3.0. The good news is it's never been easier to get something created and launched to the world. The bad news is that what were previously low barriers to entry for others have been nuked – there are no barriers anymore. What does this mean for Startup 3.0? Personally I think we are seeing the rise of the “Microstarts” - online products and services created very quickly and cheaply by very small teams of people.

The quintessential Startup 1.0 company was Netscape. Folk-law has it that Netscape's pitfall was rewriting it's core product suite, a colossal engineering effort that occupied hundreds of developers over many years. In the end Microsoft ate into their dominant marketshare with Internet Explorer whilst they were off doing this rewrite and Netscape sold out to AOL in 1998.

In contrast, to me the poster boy Startup 3.0 company is Twitter. Founded in 2006, the first prototype of the software was written in 2 weeks by a small team. Even today with 20 million unique visitors to their service per day the company still runs with only around 50 employees.

Lightweight, fast, innovative services like Twitter are created to get something new out into the world and see where it goes. Minimal startup costs allow services that have unclear business models to be launched (the founders of Twitter doubted if it was "useful", they just knew that it was "cool and fun") .

If Startup 1.0 was “build it (expensively) and they will come” (they usually didn't), perhaps the Startup 3.0 mantra is “build it (cheaply), see if they come, then figure out how to monetize it”. When your Release 1 launch costs can be as low as $100 of cash outlay you can afford to be less focused on ROI or NPV and more focused on customer value propositions.

Or in startup speak - “building something really cool that people will enjoy using”.

Working from Home - The Rules

This is the about the fourth or fifth time in my life I've spent a decent stretch of time working from home. By decent stretch, I'm talking about weeks at a time here not the negotiating with your boss to "work from home" on Fridays kind.

There are a few Rules I've formed for myself over the years for effectively working from home. These are rules for those of us that have some seriously ambitious goals we want to achieve. If however by "working from home" you are aiming to reclaim some unpaid overtime from The Man, then skip ahead - there are no rules for that (other than "don't get caught!").

These are rules for budding Entrepreneurs or Intrapreneurs that are utilising a home environment for the peace, quiet and opportunity to create something new and amazing. A home office environment, when properly setup can be magnitudes more productive than an typical city office environment.

Just think about it. No meaningless meeting after meeting. No co-workers chewing your ear off about the latest, greatest programming model. No incessant chatter going on at 90 decibels. No hours of productive time wasted commuting to and from the office. No Health and Safety debriefs from the Building Supervisor.

Nirvana is within reach, provided you can Follow The Rules...

Rule 1 - The 3 S's

Follow the 3 S's. That is - S@#t, Shower, Shave. Before you even start brewing that morning coffee to drink over your Google Reader articles, get yourself ready. Shower, Shave, put on jeans and shoes. No slippers and tracksuit pants and definitely no lounging around in PJs and dressing gowns.

Work is a state of mind. One of the biggest challenges with working from home is creating clear boundaries between your work and home lives. If you work in an office in the city then there are daily rituals that act to help form these boundaries. You get up, shower, shave, put on work clothes and commute into work. Perhaps you read a book and listen to Death Metal on the train, or listen to talkback radio in the car. The point is, by the time you walk into that office you have completed a mental transition from a Home Life to a Work Life state. Likewise coming home in the evening the reverse commute process helps to provide the mental transition so when you walk back in the house you are back in your Home Life state.

Try to maintain as many of these rituals as possible when working from home to aid in the Home->Work->Home mental transition phases. The least you can do is get cleaned up and put on decent clothes.

Rule 2 - Create a "Work Space"

Stop working from the kitchen table!

Sure you can keep one eye on Oprah and the other eye looking out the window at the nice vista outside, but your Kitchen is part of your Home Life state. Working in it confuses the two states and at the end of the day you will have trouble finding and transitioning through the boundary between work life back into home life.

Get a separate room - ideally a study - and create a work space here. Everything that is work related should live in this room. Your books, printed out manuals, the photos you used to have on your desk, printer/fax etc.

If you have a laptop, get a docking station. Anchor that baby to the desk. Do not walk around the house with it. That will also blur the Work-Home boundary.

When you walk into your study, you are at work. You can apply yourself 100% to the goals you are aiming to achieve. At the end of the day when you close the laptop and walk out of the study (leaving the laptop behind!) you will have "knocked off work".

For those of you like me with young children at home, a "Daddy/Mummy Work Place" is essential. Children will find it hard to understand when you are working and when you are at home available for use as a jumping castle. Telling them "Daddy/Mummy is at work" will not work (trust me on this). They will however learn to recognise when you are in your "Work Room" you are to be left (mostly) alone. Physical cues are more effective than verbal ones for young children. It's not foolproof (I write this with my 1 year old son clawing at my leg and reaching for the mouse) but it's a lot more effective than working at the kitchen bench.

Rule 3 - Segregate your music collection

One of the best things about working from home is that not only are you removed from a lot of the distracting background noise that permeates an office environment you can actually control the background audio environment. That is you can put on YOUR music at the VOLUME you want to listen to.

At first this is very addictive. You rifle through your music collection (which used to literally involve physically rifling through piles of CDs but these days instead involves a flick of the mouse to scroll through Cover Flow view on iTunes) and play long lost albums from your youth at full volume. Something like U2's Actung Baby. Yeah baby, now we are cooking, let's get coding.

Stop right there! You need to carefully examine and segregate your music collection. The goal here is to ultimately get into a state of what psychologists call "Flow" - where you can take advantage of the lack of distractions to get deeply immersed in your activity and produce at a much higher level than normal. Music can be an important part of this process, if used properly. You don't want to be hyped up with adrenalin from playing air guitar before settling down to crack out an important algorithm design. Examine your albums and artists and think about what emotional moods they evoke in you. Go for stuff that invokes a "chilled" emotional response.

For me that's a steady diet of Miles Davis, Pink Floyd, Coldplay, Buena Vista Social Club and Tracy Chapman whilst I'm working.

U2, INXS, Hunters and Collectors, Powderfinger and Green Day get left for playing at full volume on the iPhone headset when I'm out walking the dogs around the block (I've got very energetic Labradors that prefer running over walking).

Rule 4 - Get some natural light

Where ever possible, make sure your work environment has natural light. Pull open the blinds, open the window, let some fresh air in. Take advantage of the fact for once you DO have a corner office with a window view. Who cares if it's a window view of the neighbour's fence (my current view) rather than a 50th story panoramic view over the city. It's not about the view (which would distract you anyway - that's why those big company executives get so little done), but about getting some natural light and air.

Note: Don't fall for the whole startup mythology thing and literally work from your garage. Startups should be run out of a nice home office not from a dark and dingy garage. The petrol fumes won't aid creative thinking either. Really.

With these ingredients - natural light, air and a properly controlled audio environment (see Rule 3), you can happily work for hours on end without feeling lethargic.

Rule 5 - Get out of the house at least once a day

In many of the less savoury parts of the world, political prisoners and other "enemies of the state" have their spirit broken not through physical torture but through good old fashioned solitary confinement. Recognise that working from home has the potential to have the same effect. Make sure you get out of the house at least once a day to make sure it feels less like a prison.

It can be as simple as taking a walk around the block with above mentioned over-energized labradors, or going out to the local cheap and cheerful Vietnamese restaurant with the family at the end of the day. Just get out. If you miss nothing else about working in a city office building you'll miss the change of scenery each day. This may not be obviously apparent on Monday but trust me by Friday you will be climbing up the walls.

If you feel the need to be productive, collect a series of interesting blog posts and articles you want to read. Print them out (yes, that's right - print - go ahead and kill some trees, you are probably using a fraction of the paper footprint you were in your old office job) and take them (not the laptop) to a local cafe and chill out whilst you read them.

Finally - get out at the weekends! You are structuring an at home work environment to be as highly productive as possible during the working week, but remember there is a real risk of burnout if you try and get 100 odd hours of programming time done week in, week out. Use the weekends as a pressure release valve. Head out somewhere with the family - it'll be nice to reward them for giving you some space during the week by spending some quality time with them.

Don't forget also that when you get truly, deeply immersed in creating something and/or solving a particularly tricky problem it is invaluable to allocate some tasks to the background processor - i.e. the subconscious. I've lost track of the number of tricky problems I've cracked on a Sunday afternoon whilst out and about trying not to think about work as the subconscious background processor did it's magic and an answer bubbled up to the surface.

Rule 6 - Earn and take disciplined time limited breaks

For the truly motivated entrepreneur, working from home is an opportunity to work without interruption on their projects. As mentioned above, the risk is not a lack of productivity but over-productivity resulting in mental burn-out.

I like to take a trade-off position by taking a couple of breaks during the day. A break could be a walk in the park (see Rule 5) or it could be reading a chapter of a novel. It's important that the break be rewarding and non-work related (i.e. don't go read a "Mastering XML Schemas" book).

The important ingredients to this break process are two fold.

Firstly, earn the break. Set yourself mini achievable tasks through-out the day and the minute you achieve them stop and take a break. For example "My goal this morning is to write a blog post about working from home". My reward when I finish it will be to grab a cup of coffee and chill out by reading the newspaper. By making the break a reward for achieving a goal you remove any sense of guilt and replace it with one of an earned achievement. For many success orientated personalities the biggest challenge of working from home is dealing with the sense of guilt that you aren't "working hard enough".

Secondly, make sure the break is time bound. The "dark side" to the success orientated personality is the "guilty pleasure" of being able to immerse yourself in a book for 4 hours. Without a boss or fellow co-workers to provide boundaries you need to bring some discipline and set out up front how long you will spend on your break.

Rule 7 - Eat properly

If you are like me, then odds are when you work from the office you eat badly. You skip breakfast at home in favour of a Coffee and Muffin deal from the local cafe. Instead of making a nice salad for lunch you grab a carbohydrate laden take away focaccia. Or even worse, a Parma & Pot (non Australian's see here) from the local pub during one of many "team lunches". You drink too much coffee and sugar laden drinks, leaving you unable to get a good night's sleep at the end of the day. This in turn leaves you feeling tired in the morning with little appetite (hence the Coffee and Muffin on the way to work) and the need for more caffeine and sugar to provide the energy to get through the day.

Working from home provides the environment to break this vicious cycle. Take advantage of it. Eat a healthy breakfast. Have fruit for morning and afternoon tea breaks. Limit yourself to a single coffee and drink water through out the day. Utilise the 2 hours of commute time freed up to get into the kitchen and cook up a protein laden quiche. Seriously. You'll reduce the levels of caffeine, sugars and carbohydrates in your system and move away from high levels of adrenaline and stress.

Rule 8 - Chill out at the end of the day

Finally, it is important to have a clear end point to the working day to make the transition from a Work Life state back to a Home Life one. I recommend two approaches.

Firstly set a maximum end time to the working day. It doesn't have to be as early as 4pm (you aren't a public servant or bank teller) but don't make it as late as 9pm. Make it before dinner, preferably about an hour before. Personally I make it around 6:30pm (and start a 7:30am).

Secondly if you finish something really important or achieve a key milestone or goal within say an hour of your maximum end time then stop. Don't start something new with an hour to go in your working day, it'll just encourage you to work over.

Likewise if you fail to finish something intractable by this point stop. It'll be there tomorrow. And don't forget about the subconscious background processor. Delegate the problem to it and see what it comes up with overnight.

Once you walk out of the study at the end of the day make sure you are leaving the work environment behind. Do something clearly non work related such as kick back on the couch and watch the news (whilst children again use you for a climbing castle).

Why all the Rules?

Working from a home provides the opportunity to create an ideal work environment. For knowledge industries such as IT, the right work environment that enables a Flow state can lead to magnitudes higher productivity than what you would achieve in a normal city office environment.

At-home startup ventures should try and take advantage of this leverage factor to create something substantial in a short period of time (especially if they are out of work in the meantime).

The danger for the type of people that are motivated to spend large periods of time working by themselves to create something ambitious and new is not being under productive but being over productive. These rules are designed to get you into an optimal state of flow for the optimal period of time.

Now stop reading and go create something cool already!