hllau

I am googling around as I find myself in this turmoil of whether rewriting the web application again for my startup. It seems the clients want something different from what I was originally thinking. While I really appreciate that my client has given me enough feedback to let me know what they really want, I find the codebase harder and harder to maintain when changes of requirements come through.

At this moment, I have been postponing to launch it as late as possible to test the market and see the feedbacks, as I want to product to be usable to multiple clients. Writing bad codes to attract early users is never a good idea, because I am afraid that I will end up with unmaintainable codes which is hard to respond to further changes in the future. My clients are mostly senior people in their industry. They understand their problems, but they do not understand technology. The only way that I can see if the software fits their requirements is not through piles of documentations and many official meetings – something that most big companies would definitely fail in what they call themselves as “project management” skills. The only correct way to see whether the client likes the software is through producing it, showing it to the client, let them use it and listen to their feedbacks afterwards. Customers do not just want to see the product presentation, they want to have a feel of using it, but they also want to control what is happening despite the fact that they are horrible at explaining what they want in a tone and with the amount of details that developers understand.

At this moment, I will do whatever it takes to get my product fits their needs, even if I have to throw all the codebases and rewrite the entire thing, I will do it! The reason is that, if I do not do it right now, I will need to spend twice or even thrice the efforts to make the changes after the product has launched in the coming few months. These several months are going to be critical.

Here is a blog post by Steve Blank on http://steveblank.com/2011/01/25/startup-suicide-–-rewriting-the-code/. It’s a bit old but I think it’s a good article. I do not completely agree with his viewpoint, as there are always costs, benefits and risks involved in every decision. The discussions underneath the blog post is worth reading. Their arguments present a good general perspective to whether rewrite the codes or not.

No good engineers would work with old codebase, because they believe they can reinvent a better wheel. This is probably true.

An adventure is any experience that takes you beyond your comfort level. This thrilling feeling has become an addiction. A life devoid of adventure may be secure, but it is one that lacks texture and color. Societal and cultural disapprovals would impose fear, discouragement, disappointment, setback, rejection or even loss. What is wrong with being curious?

It has been very unpleasant that the reminder pops up every time when I turn on my Mac. After googling for a long time, there are still no correct answer. This may be useful and save time for the next person who has similar problems.

The correct procedures to disable Office Reminders:

1. Open Microsoft Outlook 2011.
2. Select “Outlook” –> “Turn Off Office Reminders” on the context menu.
3. Close the current instance of Office Reminders. Done.

From R. Shekar, Polaris Software:

1. Those who do the job as asked to be done by their bosses.
2. Those who do it according to the best of the available options given to them.
3. Those who do it as per the best option known to them.
4. Those who think independently about the job given to them, who think in a different innovative angles and accomplish the task in a manner as to not only fulfill the given task but also facilitate better prospects for the company and augment the revenue of the company.

Which type of staff have I been?

Some inspiring points from Warren Bennis and Dan Goldsmith (1997) who identify some differences between managers and leaders. Are you on the LHS or RHS?

Having been using Python for almost half a year, I just found out the Zen of Python today.

import this

You will get the secret Zen:

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren’t special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one– and preferably only one –obvious way to do it.
• Although that way may not be obvious at first unless you’re Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it’s a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea — let’s do more of those!

I particularly like the two lines about now, never and right now.