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.
Friday, August 24, 2007 6:10:48 PM (GMT Daylight Time, UTC+01:00)
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.
The solution here is to break the project into mini tasks and hand them to different developers and never outsource the core of your software.
Wednesday, August 08, 2007 5:21:47 PM (GMT Daylight Time, UTC+01:00)