Parveen Kumar’s Blog

There is often this debate about perl vs python. Which of these two is better? Some of my observations:

• Perl clearly has a long history and virtually whatever you can imagine is available in perl.
• Python has a more readable syntax. Easier to understand inherited code.
• Little better OOP syntax in Python.
• Powerful compact code can be wrriten using filter,lambda, etc. in Python.
• Perl is great for powerful unix one liners. e.g. Compressing the whole html directory recursively before pushing to production can be done in one line.
• Python is blessed by google and Perl by Yahoo.
• Getting Perl developers is easier than getting python developers.

If you are looking for a new language for building large softwares, then python seems to be better choice.

These is a pretty good comparison of various wikis at:

http://www.onlamp.com/pub/a/onlamp/2004/11/04/which_wiki.html

I found  MediaWiki to be reasonably good choice. The installation is pretty easy and it uses php and mysql which work nicely on any system.

Very useful blog by Ken Norton

http://heynorton.typepad.com/blog/2005/06/how_to_hire_pro.html

I have been heading the engineering of few products at MIH Web PVt Ltd for last 6 months. Its has been a great experience. Officially I’m employee No. 1 of MIH Bangalore. Life here started a little bit chaotic. I did lot of shuttling between Bangalore and Gurgaon. I still remember going to Divyashree chamber, Stylus, Regus, etc. places with Rajesh and Ruban to decide on office space. Then came hiring. Hiring first few employees is also a challenge. Our success rate was very low initially but we crossed that stage soon. Thanks to my first two team members Tulika and Abhinav who helped me get more great engineers. When we started growing, many times we started focussing on wrong problems. But that got corrected soon. We kept building products. It is very satisfactory to see the outcome of hard work. Some of the key lessons I learned:

1. Architect your product keeping performance, simplicity and streamlining in mind. Scalability is also important but don’t spend too much time on it if it is not needed in 1-2 years.
2. Be Ready to take U-turns. Accept mistakes and correct them early.
3. Be honest with yourself. Don’t convince others on something you don’t believe yourself. If you are capable of convincing others on wrong thing, unknowingly you will start convincing yourself too on wrong things.
4. Get your hands dirty with everything. That is the real fun of working at a startup. That way you can empathize better with others.
5. Don’t focus on solving more problems. Focus on solving right problems.
6. Provide your customer (product folks) what they need not what they ask for.
7. Don’t just bring up problems. Propose solutions also.
8. Keep transparency. Thats solves many problems.
9. Think end-to-end from day one.
10. Avoid 80%-20% trap. Many times we spend 80% of our time in solving problems which are only 20% important.
11. Don’t over-engineer. Most problems have simple solutions. Solve them first. Many times we start solving complex problems and fail in solving simple problems.

As you build your product many bad features will creep in. And in a democracy removing a feature is 10 times more difficult than adding it. So key to building a good product is remove as many irrelevant features from your product. Just focus on your core features and don’t show anything extra to users in your product.

Companies are started keeping some goals in mind. To achieve those goals we create sub goals and then sub-sub goals.

The person trying to achieve sub-sub goal may not know (or may forget) about originals goals. And often original goals change. The change is more frequent in web domain than in any other industry. When goals at level 0 change, we don’t get time to update goals at level 1 and level 2. This is more common than not. So many times we end up building something which is not needed. To avoid this situation everyone should always be aware of level 0 goal.

Most of us will agree with this to varying degree of extent. In the context of web product development, this is more true. It is important to do a dryrun of project before we start execution. Once you have started execution, innovation becomes difficult.

It is important to take into account factors like:

• People sometimes don’t know what they don’t know.
• People over-commit in meetings.
• There may be chemistry clashes.
• People may leave during projects.
• People may need training.
• People may not execute someone else’s vision nicely.
• Technology may give surprises.
• There may be too many email exchanges/communication on something which you think can be easily communicated.
• The product/feature you are trying to build may get outdated before it is built.
• The vision of the leader your are trying to execute, may change before end of project.
• People don’t improve something for which they don’t get credit.
• We need to answer “what is in it for me?” question everyday for everyone.
• There may be too much democracy or dictatorship.

I guess this list is getting too big. I’ll stop now.

This is a very common problem I see almost everywhere. We build systems to achieve some goals. But soon those systems becomes our goals. We start focussing on solving system problems and completely forget about our real goals. Then we build more systems to solve these system problems.

I guess that is why startups succeed. They don’t have to carry the baggage of old systems which are not easy to get rid of.