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.

Ten things about me

1. I'm a software engineer with a very technical background

2. I'm interested in the business side as well

3. I'm trying to combine 1 and 2 in my tenapes project

4. I'm in full time employment at the moment

5. Because of 4. I develop the tenapes project in my spare time

6. Because of 5. the tenapes project is quite late

7. I will be using my product myself - which is a definite plus

8. I'm struggling with this blog and trying to find interesting things to write without insulting the intelligence of my readers and without falling behind too much

9. Sometimes when I fall behind too much with my blog, I pre-date the entries to make it look like I'm not falling behind (Uh, that's a dirty trick!)

10. Points 8. and 9. work for now because not many people read my blog ... just this guy googlebot and some of his friends (sad I know!)

Five things about my product

1. It is a niche product

2. It is a specialized tool mostly for developers

3. It runs on Windows

4. It is written using C++, VC++ 2005 and wxWindows

5. It is still under development, so I will share more about it later on

Micro ISV

ISV, definition from Wikipedia:

Independent Software Vendor (ISV) is a business term for companies specializing in making or selling standardized software, usually for niche markets, such as that for real estate brokers, scheduling for healthcare personnel, barcode scanning and stock maintenance.
 

Micro ISV is a term invented by Eric Sink when he used to write for the Microsoft Developer Network. A micro ISV, as the name suggests, is a very small software vendor, usually with just one software developer responsible for everything from writing code to managing sales, marketing and PR. If a company has more than 5 developers or gets venture capital, it is not considered a micro ISV.
 

Micro ISVs take full advantage of the power of the internet to recruit customers, sell and manage their supply chain. This ease of interaction with potential customers make micro ISVs very attractive as the start up cost for a micro ISV is very low. Anyone with a computer, programming skills and a good internet connection can create software and sell it online, irrespective of their location in the world.
 

In his book "The world is flat", Thomas Friedman argues that the Internet is a major flattening force that allows small companies to act big. Anyone can establish an online presence and appear to be bigger than they actually are. They have easy access to technologies like CRM that allow them to provide the same service as big companies. Sometimes small companies, keen to succeed, they provide an even better service than bigger companies.

Source version control fable

Fred wrote code.

Fred is an intelligent software engineer working for a small startup. He has to write a small demo for his company for a product they want to raise money for. He knows time is short. So he starts writing the code. In the evenings and weekends he dumps everything on a disk and takes it home where he continues improving it. Sometimes he runs out of disks and he emails himself the code back home. Or sometimes he just uploads it on a FTP server which he can access from home. He is a passionate employee.

The first demo goes relatively well. He gets requests for more features to be added to the demo based on the feedback of the first demo. He keeps working at the office and at home. He keeps emailing code, burning CDs at the end of the week or FTP-ing the demo source code on his own private server. The following demos go well and the company secures funding.

When Fred is interviewed later on about his efforts, he mentions the following problems and things he would do differently next time.

"Working with the same sort code at work and at home definitely contributed to the overall success of the project. But the source code management was very poor and it was one of the problems frustrated me the most. I started with the naive idea that I'm working on a demo which we'll throw away in 3 months. As such, I went for something quick and dirty. It was frustrating.

I would need to get the whole source tree, zip it, put it on a disk or email it. Once at home, I had to either overwrite everything, or if not sure, do a diff against the code I had at home. It's painful and you have to repeat all these steps this every time."

Moral of the story: Don't underestimate the importance of a version control tool even for small one-man projects.

Who wants to steal your source code

The source code is the bread and butter of every software company. As such, having your source code stolen must be one of the most frustrating experiences. What's the worst it can happen though?

1. Someone else uses it to build a clone of your software and make big money competing with you

Usually it takes time to transform source code into something that looks differently. But still, there are companies that do it. There are many companies secretly using GPL code for example.

Your options: If they start making big money, you can sue. That's if you can figure out it's your source code they're running.

2. Hackers use the source code to expose and/or exploit security holes in your software

This is nasty. Sometimes hackers will use these security holes silently and it will take a long time before you discover the problem. You might even get sued by compromised customers if you're not careful.

Your options: Keep a close relationship with your customers, ask them to submit problems about your software. Conduct regular security audits. Be serious about security and try to identify security holes internally or working with a specialized security expert.

3. Your competitor got their hands on your source code and they use it to improve their product

This can pose serious problems, especially if you have innovative technology that you invested a lot of money and effort into. However, usually it takes time to refactor source code and integrate it into another product. So it's not as bad as it seems.

Your options: If you can figure out they have stolen your source code, you have the law on your side. In order to protect innovative ideas, you can patent them.