Writing blog posts seems to require a certain emotional threshold to be crossed. No wonder micro-blogging is really popular, no real thresholds to cross there, visiting the restroom constitutes a post. Rank amateur bloggers like me have to expend quite a bit of effort in writing a post (even with posts that reflect the amateurishness), that effort requires some emotional energy. That emotional energy, I would argue seems to come more easily when a person is frustrated or angry. The next time you read a bunch of blog posts, try to gauge the emotion behind the post, count the number that you think were not fed by frustration or anger (anywhere in the spectrum from mildly peeved to a foul rant counts). In fact, some of the funniest posts are rants, nothing like an expletive to let off steam.

I have been working solo for the last few months using Erlang and Flex/Actionscript. The technologies I have been working with (especially Erlang) have been an absolute pleasure. Flex tends to be big and bulky, with APIs running amok, lots of choices to do the same thing, but somehow it all hangs together very nicely.

So, why this post ? Well, some of my old frustrations came to the fore when I saw this new language fan. More specifically, when I read a few lines describing the features in the language – REST oriented transactional memory. Reading further, I came across this line – Resources may be mounted into a common Uri namespace as a “shared whiteboard”.

What does this have to do with my frustration ? In one of my projects in the past, I proposed this very same idea and met with the most unreasonable resistance I have ever come across. Resistance that would have required plenty of machiavellian tact to overcome, something I did not have the inclination for at the time.

This is what is so great about open source, a movement I feel guilty for not having participated in so far. I hope to remedy that in the future. I hope Fan succeeds, they have some very good ideas (including message passing concurrency based on Erlang). Even if Fan does not succeed, I hope ideas like REST oriented transactional memory have a shot at gaining acceptance. I am now emotionally vested in seeing this idea survive, may it live long and prosper.

Patrick’s post on AppJet and my comment on their ability to make money made me dig up this old draft. Every software project you work on, whether it is in a startup or in a big company will eventually get asked the question – how will this make money ? Having thought about this question a bit, I think a much better question is – who will find this useful ? A subtle difference, one might argue, but I think it makes a big difference in how you design a solution.

The “making money” part has to be a side-effect of “build something useful”, so in that sense AppJet is on the right track. Promote money making to be the primary consideration and you will either end up in building a strong sales operation or a bad product (sometimes both). Selling is important and often a difficult task (one which programmers have very little appreciation for). However, it cannot be the foremost concern for a software project in it’s infancy.

If on the other hand you decide to build something useful, you will always focus on delivering something useful to a customer. Once you have succeeded at that, money is more likely to follow. More likely, not guaranteed. Google struck gold by building an excellent search engine, the ad revenue followed. That does not however mean much to all the other startups out there.

Finding a good answer to who will find this useful will contain clues on whether it will make money. The problem is, most of the time, programmers focus on tools other programmers will use. AppJet is an example. In my opinion, this is usually indication of something that will not make a whole lot of money. Examples include, the next big programming language, a compiler for the next programming language, the next big web framework, a framework for building frameworks, tools frameworks that build frameworks and other recursive framework related projects. These projects are ideally suited for open source and if successful, will end up in services and support based revenue streams at best.

Maybe AppJet will succeed with a lean, mean utility-like hosting model, differentiating itself from all the other hosting providers with a novel app development platform or maybe as Patrick pointed out, this is all just a big bubble.

This is a synergistic organic blog post meant to innovate and increase a value’s proposition. I had to nurture it within a broader context and leverage strengths to deliver value. Keeping everything organic, while the synergies evolved and matured. The innovative, synergistic value proposition had to be clearly articulated while the post matured and nurtured the organic content. Ultimately, this is all about value. Value and organic matter delivered in a nurturing fashion while your strength is being leveraged. The post is based on a great track record, set on organic tracks, where the synergies in the broader, more complex eco-system helped the grass mature. Leverage was applied all the time. Propositions and their values, living in the broader eco-system, synergistically maturing, leveraging track records, delivering an organic opportunity.

Tipping the point and chasm crossing can also be accomplished by identifying organic opportunities which leverage synergies. Organic organizations that keep tipping points eventually overturn, giving them a great out of the box perspective on the synergies in the box. Frequent chasm crossing can help in leveraging strengths that help in identifying (organically, of course) customer opportunities, establishing a strong track record. This post will continue to organically grow in the comments section.

As programmers, most of us want to build things better, faster and cheaper. We are taught big O analysis in our first algorithms course, we never give up optimizing. We love projects that relentlessly simplify. We find compact and powerful languages attractive and surely the next language is better than the previous one. We always want to do more with less, but if we do more with less, shouldn’t it be cheaper too ? Yes! we answer and most of the time we are wrong. Better, faster are great goals but cheaper does not pay the bills.

Let us look at the variations, there is better, faster and costlier. This one makes for a great (arguably, the best) business model. Intuitively, it makes some sense, as human beings we are irrational and emotions trump reason frequently. Evoke strong positive emotions and people will gladly pay you a premium. A lot of great engineering has to go into these products though, it is not just about looking good. If a software company can pull this one off, it is the best way to get rich. The problem is that other programmers are constantly looking to making your product better, faster and cheaper. Eventually, your product will become a commodity.

There is worse, slower and cheaper. This one is also easy to understand, you get what you pay for. If you can churn widgets out quickly and for a lower cost, you can make money on volume. I don’t think software manufacturers have figured out how to make money with this model. The closest I have seen this work is the discount bin for computer games at the local electronics store. A number of hardware manufacturers on the other hand thrive this way.

Then there is worse, slower and costlier. This is the most confusing business model because it just should not work (in theory). And yet, it does. No product starts out this way, they all start out in the better, faster and costlier mode. On the road to commoditization, some successful products end up in this state. The reasons vary, in becoming successful, some products become monopolies. Some of them are part of very complex software systems and complexity resists change. There are probably other reasons involving human factors. This state can last anywhere between a couple of months to a few decades. No one can predict the duration. The complexities of macro economic systems are unfathomable.

This state is a programmers worst problem, because we are supposed to make things better, faster and cheaper. But, remember, cheaper does not pay the bills.

The best way to kill a nascent debate is to use the line “if you think I am wrong, prove it”. This is one of the most clever ways to avoid criticism (constructive or otherwise). It does not quite close the door on dissent, while effectively slamming it shut.

The problem is that something has to be provable for anyone to prove it. Proving also requires a lot of effort or a lot of time. So, the next time you need to make a controversial decision, make the decision and then use the line if you think I am wrong, prove it. In all likelihood, your decision will stay.

Of course, you still have to be right…….and time will surely tell.

I was reading this article in the latest issue of Newsweek about how speech recognition software has apparently become usable. I have not tried speech recognition software recently. The last time I tried the software managed to produce complete gibberish, I don’t think that was entirely due to my Indian accent. The article analyzed the reasons for why the software had become more usable. Better hardware seemed to be one reason, faster CPUs, more RAM.

The other reason was what caught my attention, apparently the market leader in speech recognition embedded what sounded like a feedback sub system in their software. With broadband connections becoming widely available, users don’t mind if their software talks to the mother ship. In this case, every time the software made a mistake, it sent details on the mistake back to home base. This enabled engineers to tweak their algorithms constantly.

I wonder if Enterprise customers with their myriad firewalls and network security protocols would allow such feedback loops. Yet, without these feedback loops, how can one make a product better ?

I have been finding out the hard way that tires and nails on the road don’t mix. Just went through my 3rd nail in a tire in the last 12 months, this tire could not even be fixed since the nail was too close to the sidewall. So, here is an idea for one of these gadgets that you see in infomercials and shopping catalogs – a magnet that sits in front of each tire, picks up nails before they can hit the tire. If anyone builds such a gadget, please let me know.

I have been a member of Netflix for a long time now. Getting decent recommendations becomes important after one has watched 500 movies. So, in the hope of getting good recommendations, I faithfully try and rate movies that I have watched. The rating system requires between 1 and 5 stars. If you have followed the buzz around the Netflix prize, you will know that Netflix is very confident about the statistical underpinnings of their rating software and I have no doubt they have done a good job.

But, here is my problem, what if the ratings data is flawed. My ratings for a movie depend on a lot of factors, the context I watch that movie in. My ratings are only valid for that particular context. If the person sitting next to you keeps yawning through a movie, you are much less likely to like it than if you had watched it alone. Laughter is infectious too, bad comedies are likely to get a great rating, if the person next to you laughs out loud for every bad joke. Watching Monty Python with someone who does not quite get it can be a drag. Moods play a big part too, I am much more likely to enjoy a scene where a bad guy gets his teeth kicked in when I am a little peeved myself. The same scene would be abhorrent if I just finished reading the latest new age essay on compassion.

My ratings are very inconsistent. Capturing the context is hard, but it seems like it is an important piece of information in the ratings game. This is true of almost all ratings. Tirerack does a nice job of having reviewers add information about their driving style, but more is needed.

Joe has an interesting link on procrastination . Very appropriate for someone who is starting a blog after thinking about it for a long time. The author even has a formula for procrastination, but I wonder how one quantifies the variables – “the desirability of the task” is one such. A question like – on a scale of 1-10 how much do you want a blog, is much more difficult to answer than a question like – on a scale of 1-10 how much do you want a Porsche. The answer to the second question is the same at any point in time, the answer to the first one depends so much on my context on that day/hour.