The art of staying on track

One of the most challenging things of trying to start something is to continually motivate yourself and stay on track. All people go through ups but also downs - points where their motivation is at its lowest. That's the time to take action. The longer you wait, the more difficult it is to make a come back.

The 'tenapes' project is a continuous learning experiment for me in the art of staying on track. Here's a list of six important things I have learnt:

1. Get into a simple everyday routine

It's simply not working trying to work whenever you have time. It is much better to set some time aside for your project. Try to wake up one hour earlier every day or go to bed one hour later and spend that time working on your project. One hour it's not enough, but the routine of it will force you to get into the mindset of "delivering" every day. A very powerful thing for staying on track.

2. Bridge the gap in small steps

One of the biggest problems in software engineering in general and in building something on your own is that people don't know how to bridge the gap between where they are and where they want to get. Usually the objectives are expressed in generic or abstract terms and people only realize that when they have to get them done. The key here is to build a mini roadmap of how to get from 'now' to 'shipping date'. Ask yourself the question ... What can I do next? Or, for a top-down approach ... decompose your abstract goals into very refined tasks that you can do next.

3. Stop reading and DO IT

In the information age, we're constantly bombarded with tons of information from all directions. It's so easy to get carried away and read blogs, watch clips on youtube or try to find the latest hype in the whole it will all give you a bit of competitive edge. The biggest challenge is to realize that your time is finite and all the time spent doing these things is time spent away from DOING. Away from building what you're supposed to be building.

4. Reinforce your vision every day

Guy Kawasaki in his book "The art of the start" used a very appropriate analogy between business/development attitudes and microscopes vs. telescopes. When you're DOING, you're working with the microscope. That can be tiring and it's easy to lose motivation and confidence in your own project, especially when you bump into problems. That's when you have to use the telescope, look at the bigger picture, think about what you're doing and why, think about the big vision that's motivating you. Once your energy levels are replenished, you can go back in front of the microscope.

5. Don't give up unless it's time to give up

Never give up for the wrong reason. The wrong reason is always lack of motivation, procrastination, not doing what you're supposed to or finding it much harder than you'd thought it would be. These are problems and there are problems in everything ... don't give up just because it's not a walk in the park.

However, giving up can happen for the good reasons. You might discover that you jumped into an idea before doing the proper market research and suddenly you discover people that do what you do but better. Then it's time to ask yourself ... how am I different from these people? If you can't find a satisfactory answer, give up and put your energy into something more useful.

6. Learn from mistakes
It's useful to write your past mistakes and/or conclusions on a paper. Externalizing the information makes you more aware of it. Think how these mistakes and conclusions apply to your current situation. Are you repeating them? Maybe in a different form but same root cause?

A moment of honesty with yourself can work wonders.

Outsourcing on rentacoder

Outsourcing is a big topic and rentacoder.com is an established company already taking advantage of the trend to outsource projects or parts of projects. They cater for the small to medium businesses. I have used rentacoder twice so far, for two small sub-projects and I have decided to write in my blog about it.

There is a certain attraction towards outsourcing. The very idea of getting some help from someone else and shipping my product earlier than planned is very attractive. In every project there are parts that are tedious, not very attractive or require a lot of time but they must be done. These are the parts that it is so easy to convince yourself that you'd be better off outsourcing them to someone else.

At the same time there's an inherent fear that comes with outsourcing and losing control over certain areas of your code. While the attraction is obvious, here is a list of my three main fears when it comes to outsourcing.

1. Quality

I'm not sure how good the result will be and while I can set some clear goals for the project, I definitely need to check that the goals have been met. That means writing extensive acceptance tests, test plans and performing extensive manual testing. Again, I could outsource this task too, but then we'd be going recursive.

Quality is not only restricted to the functional aspect. It is also the quality of the source code, how maintainable it is, how extensible it is, etc.

2. Detailed specs

Outsourcing forces you to write very detailed specs. You have to cover even the most obscure corner cases, otherwise you might get back a lemon. If you want control over HOW not just WHAT gets delivered, then you will need to write design/architectural specs in addition to functional specs. You might even have to write code templates.

The risk here are obvious:

      a. Provide too little and they might come back with too little or too badly designed/implemented (funnily enough, it might be exactly what you've asked for)

      b. Provide too much and it will take you more to write specs than it will take you to do the work yourself

The positive side is that writing specs forces you to think about use cases, even obscure ones. You might discover flaws in your thinking and in your assumptions.

3. Source code leakage

Giving away your source code is always risky. You can sign NDAs as much as you want, but in a global world, you soon find out that you can't enforce NDAs easily, especially if you work with developers located in places like India or Russia.

The nightmare scenario is to wake up one day and find out a clone of your software, doing exactly the same thing, sold at a fraction of what you're selling it.

Why do small startups write blogs before having a product to sell?

I think answering this question involves a lot of market research that I cannot afford both in terms of time and money. So I'll answer it from a very personal perspective. So let me rephrase the question.

Why do I write a blog before having a product to sell?

Well, here's how I convince myself to write entries into my blog:

1. It's good because you will have a 'mature' domain name. Search engines usually rank websites based on how 'mature' they are, among other things. That means ... how long they've been around for. Having something online, even if it's just your pre-shipping blah-blah-blah, it's good for enough for bots and search engines.

2. It's good to build up content that search engines can index and start ranking your website. Content takes time to build up. The sooner you start, the better.

3. It's good if you manage to grab attention or hype up your product before it is launched. Making your potential customers interested is great since that means potential sales from DAY 1. It also means you might be able to find beta testers more easily. But generating buzz is no easy thing to do. Blogs are no guaranteed recipes for success and if you don't know how to use they can have a dark side.

4. It's good to reinforce your vision and share your vision with the world, even if you only do it gradually.
It can be a tool to re-motivate yourself, primarily by getting back in touch with your vision behind the product, project and ultimately the main reason for writing the blog.

5. It's learning exercise.
The main reader of the blog is the writer herself. Writing can be a good tool to find out what you know and what you don't know, what you can and want to share with others and what you can't or don't want to share with others. It is a good exercise to force you to think about the dusty corners of your endeavour.

Business resolutions

Last year (or 6 days ago) I promised I would share my business resolution with all my readers. It is all part of my effort of committing myself more to openness and transparency. So, after long deliberation, here's the list with my business resolutions for 2007

1. Keep writing the blog, at least once a week

The blog is an interesting tool that helps me communicate to the world. It is the main means of achieving openness and it is extremely useful in keeping track of the effort involved in developing an application. However, blogs are sometimes easy to ignore and writing regularly can become a tedious task. That's why this resolution is here to remind me the importance of updating this blog.

2. Set clearer milestones for the development of my application

When I have started the application, I haven't had clear dates either for delivery or for intermediary checkpoints in the lifetime of an application. While developing the application I soon realised that these are absolutely required. I have a great experience working in the corporate world and developing software. But when developing your own application, it is somehow different. You have to wear a multitude of hats. A development hat, a project management hat, a line management hat, a self-motivation hat, marketing hat, writer hat, sales hat, etc. That's an impressive collection of hats and keeping track and managing your collection can be quite challenging a task. This resolution is a commitment to a clearer and simpler system for managing the development of my application.

3. Set a date for release and stick to it

This resolution goes hand in hand with resolution number 2. Setting a date for the release of your application is important because it forces you to think about the amount of work involved, the work left. It also forces you to postpone some features for the next release once you realize it would take too long to include them in the current release.
Last but not least, having a clear date that you can stick with provides a very good motivation to keep going. It is an articulate goal, very easily measurable.

4. Decide when to share the release date with the readers

This last resolution is probably the hardest of all. Committing to a certain release date is hard, but sharing the date with everyone else is putting a lot of pressure on the whole. If you're not able to deliver it in time, you would be perceived as a failure by your potential customers. If you're not Microsoft, you can't afford to do that. Yet, I'm willing to try and see where this road takes me.