The Microsoft SQL Server 2005 pricing model is transparent, online and in your face for you to decide if the product fits your pockets.

MySQL on the other hand seems like a "call us to find the price" operation when you first Google for its pricing.

The kind I prefer referring to as the Mafia Ransom Pricing Model.

Even though MySQL is in reality not a "call us for pricing" operation I cringe every time I see marketing guys show their famous "call us for pricing" move.

Pricing is hard. Pricing takes a lot of experimenting. You can never price your product to please everyone.

But that does not mean that you run away from the problem all together, hoping that your potential customers will call you every time they want to know the price of your product and then they will spend countless hours haggling with you.

The "call us for pricing" approach tells your customers that you have no clue about what your product should be priced at.  It also tells the customers that you are going to charge each customer differently not on the value your product provides but on how much the customer is willing to pay or a host of bizarre factors.

Consider this line on MySQL pricing page for instance:

With MySQL Enterprise Unlimited, companies with up to 1000 employees can deploy an unlimited number of MySQL Enterprise Servers, with full 24x7 production support for a fixed price of $40,000. You also get unlimited 24x7 access to MySQL Enterprise Monitor.

It does not take a rocket scientist to catch a bad vibe about the pricing model if you are somewhere in the nine hundred employee ball park and are looking to hire more people. What happens when you cross a thousand employees? You call up folks at MySQL and haggle with them?

Ever wondered what the correlation is between which database your project uses and how many employees your organization has? None.

To understand this concept of "no correlation" between what you charge for your product and what the pricing depends on, lets start by assuming that we had an awesome word processor that you were interested in buying. We started off with the "call us for pricing" tagline on our website. Now lets assume that out of the hundred customers that saw the website and the ninety seven who never came back, you fall in the range of three customers who did.

Let's also assume that you actually picked up the phone and decided to give us a call. On the call, we told you, that what we charge you for the product is going to depend on what kind of documents you choose to write with our word processor.

If you write a blog post that no-one reads, we would give you the word processor for fifteen dollars a license but if you were to do the sales deed of your home on it, the price of the word processor would shoot up to five percent of the deed price.

Picking important factors which have strong concrete correlation to how you price your product is also important. Pricing a database license based on the number of users or processers is perfectly fine but pricing it on the number of employees in my organization is as messed up as pricing a word processor based on what I plan to do with it.

MySQL does seem to have a well defined pricing page too and this post by no means is an attempt to thrash MySQL. The point of this post however is to convey the central idea which is this:

Every time I see a product website with well defined versions and price tags attached to these versions, I make a decision based on if it fits my pockets and needs. Every time I see a "call us for pricing" tag on the pricing page of a product, I cringe. I almost never call. But then again, maybe that is just because I am a geek. Pricing is a hard problem but that does not mean you avoid it. Putting a "call us for pricing" callout on your website is not an answer.

Now go figure out your product plans, prices and publish them on your product website.

I wish you good luck.

Of the first few times I recall being addressed to as a geek or a nerd, one was during my high-school days. It was meant to be a slightly derogatory remark passed in a setting which shook me up for a couple of days.

Fast forward a few years. I am called a geek again.

This time I smile inwardly and take it as a genuine complement.

Somewhere between the two remarks a lot of things changed but fortunately the Geek within survived these years. Most of him remaining unchanged.

Somewhere between these two remarks, I was also fortunate enough to bump into dozens of other geeks who had not just survived, but thrived. Flourished. Made small and big dents in their universe and had told the world around them in a loud and clear tone that they were there to exist. On their own terms. Without changing. Their weirdness, their stupidity and insanity turning into their primary survival and growth technique.

As I observed these Geeks not just survive but actually thrive and create a ruckus in their world, one of the things that absolutely fascinated me was the mind of these geeks and how it usually works. There was a pattern emerging somewhere. There was something about their mind.

It was weird. Insane. Wired strangely. And yet, it was rather fascinating.

The more I observed these minds, the more convinced I became that there is a lot to learn from these minds.

We are not talking about the Pseudo-Geek mindset here. The kind whose resume you see floating in Job portals around the world. We are not talking about the kind who can calculate their monthly take-away to the precision of decimal points after tax deductions when they look at the offer letter for their new gig. That is the race of dangerous programmers who often cannot program or professionals who will cheat and rob you at the first opportunity that they get.

What we are talking about is the mind that figures out the intricacies of an encryption algorithm and implements it but cannot get itself to care about calculating his monthly takeaway or submitting his reimbursement forms on time.

We are talking about the mind that spends hours focusing on understanding the universe and everything in it from the viewpoint of a system and the personality that tries countless ways to tweak the rules, hack them, break them or work around them. We are talking about the kind that loves doing this.

Now, if you are a genuine Geek, chances are that you have not tried understanding your brain or your thought patterns, with even one tenth the effort that you put in your last project. Of course you might have gone in and grabbed a copy of Being Geek but then do you take a pause every now and then to dissect and analyze situations where you react differently than a perfectly normal-sane-practical-human-being? No? Hardly Ever? Thought so.

This series of posts is my attempt at doing that. It is my attempt at answering how a Geek thinks. How he works. How he reacts. How he sees things. It is an attempt at understanding the minds that have fascinated me ever since I first realized that I might not be as awesome as them, but I can connect to them and understand what makes them tick.

If you are one of them stay tuned for more on the topic as this series of posts unfolds itself. If you happen to work with Geeks or Nerds and were never quite able to figure them out these articles might help you get a deeper insight into the minds of Geeks and Nerds. Stay tuned for a series of posts where we attempt to understand the minds of the genuine geek that might be sitting right across your cubical or maybe even inside you.

This classic hugely inspirational scene from Glengarry Glen Ross has been one of my most favorite when it comes to getting things done.

Having said that, I am not so sure that this is a scene young and budding software marketers or sales guys should be watching though.

Coming from a consulting background I have been a part of countless sales calls and meetings. After watching countless sales deals that fizz out, if there is one thing that I have learnt about selling stuff it is that, If you want to sell badly enough, you will sell badly. If you try hard selling, selling will become hard.

Recent discussions with someone at work reveled a fascinating story on selling his used car. This person had been thinking of selling his car for a long time.

Somewhere during this time, his friend lands up with a broken car and since this car is sitting unused in his garage, he decides to help his friend and let him use it for a dew days.

"A few days later, this friend of mine comes to me and makes me an offer for the car", this person explains. "I told him that German cars need a lot of maintenance after a few years and if he wants a cheaper used car, he should be going in for a Japanese car, but he kept insisting on wanting to buy my car".

"I guess the one thing I learnt about selling and the whole try before you buy model is that you have to have genuine interest in helping someone when you let him 'try' your product. You cannot be thinking about selling when you are helping.", the person concludes his learning from the story.

The point? If your 'try' part is focused on moving your customer to the 'buy' part you will almost never sell. If your 'try' part is focused on helping the customer and letting him discover for himself if he genuinely loves your product to come back to you and buy it, chances are that you won't sell to everyone, but chances are also high that you will hit a niche of people who will really "want" your product.

Don't try to sell to everyone. Don't try to sell anyhow. Don't try to sell all the time.

If the "Always be closing" model is not working for you, the best you can do is move to an "Always be helping" mindset and then when you see someone who genuinely wants your product, give them the line that is dotted and chances are, they will sign on it happily.

I wish you good luck.

When you are the kickass rock star alpha geek of your team churning out code by the minute and getting things done, you love being in the flow. Then slowly, as more and more people in your team realize you can help and as you accept one promotion after another, somewhere it becomes fairly obvious that if someone in your team is stuck he is supposed to walk up to your desk and cause an interruption often without asking if it is okay to interrupt.

The first few years of this 'helping mode' are fun. You are busy helping everyone. You don't really care if you are not churning out a lot of a real work yourself. Time moves on. Fast forward a couple of years. You have managed to stay deeply connected with code, but on an average you just find a couple of hours of non interrupted work in a day. There are days when the builder within you asks you the question: 'What did you do today?'.

You know the answer to the question instantly.

The answer freaks you out.

There are two knee jerk reactions possible in this scenario.

If you were the geek who always loved code, you are going to go back and assign the most complicated module to yourself, lock yourself in that cubical for days f@#king up your responsibilities as a manager and those emails from your clients are going to sit in your inbox unanswered.

If you are the guy who was never quite good at coding you are going to take it upon yourself to walk up to every developer you can find and ask them the status three times a day. You are going to answer every single email in your inbox and watch your experience as a developer go down the drain as you morph from a capable alpha geek to someone who just answers emails and talks.

Both of these knee jerk reactions are small steps towards big problems.

What you need to do is take a pause. Breathe. Let the question soak in. Reflect.

What did you really do today?

You helped Jack by taking his rather long winded function and using an API that would do the same work in half the lines of code. You researched the API. You tried a quick POC on it with Jack. Of course, it was his work but it was your job to keep him moving forward.

Then you spent time responding to emails and building a story around your product so that the clients don't just look at the data.

You picked a bug or two. Fixed those. Did a scrum. Thought about a couple of new features.

And in the process of these you answered about a dozen questions on a feature, on a decision that had to be made or a problem someone was facing. You have done enough by doing nothing concrete which you can sign off as your work.

If there is a geek within you, he is never going to see any of the above as real work so yes you do need a couple of hours a day when you are logged out where you work on keeping your sword sharp and churning out some real code.

Having said that, the sooner you get used to the idea that at some point of time in your life, you will have to stop adding items to the list of things you personally did, stop showing this list to your bosses and start spending a decently big part of your day mentoring, teaching and guiding others, even though this does not really qualify as 'real work' according to the geek that you still are, the better off you will be.

Go on. Strike a balance between teaching, inspiring and doing.

I wish you good luck.

Earlier last week we talked about the Thousandtyone youtube video channel. Last week another video on the series of Entity Framework videos has been uploaded to the channel. Going forward additional videos are expected to get uploaded and if you would like keep a track of all the topics of videos that are getting released here is a quick table of content that will get updated every time a new video is uploaded.

Going forward an additional RSS feed will also be added for the videos. The whole point of starting the video channel was collective learning. If there are any specifics topics you would want me to cover, feel free to view the list of upcoming videos, vote and add items to the list.

Looking forward to your opinions, ideas and suggestions.

Project Plans and Gantt Charts have floated around in office corridors since Project Managers have existed in the business of software development.

The thing with folks who run around with these documents and knock on your cubicle three times a day, is not they they are bad human beings.

If they could have helped the developer who is running late at meeting his dead-line they would.

But most of them stopped programming at the first opportunity they found.

Typically here is how a developer manager conversation that I often overhear runs:

Manager: "We are running really late. Do you know what is wrong? Why are we taking so much time?"

Developer: "Not sure. I mean it is pretty straight forward but this nested query keeps timing out for no particular reason. I mean this is a simple cursor that takes the data from a table, throws it in a temporary table and then filters out the data we do not need. We have done similar queries in the past and they all run just fine."

Manager: "How much more time do you think we will need?"

Developer: I'm not sure.

Manager: Can we try to do this by the weekend? Its really important.

Developer: Hmm... okay... I will try my best.

Manager: Thanks. I will go ahead and update the status report.

Can you see what is happening here?

First, none of the parties are at fault here. They are just speaking a different language. The developer is clearly seeking help. He wants someone to sit down and take a look at the nested query. The manager would have loved to help, but he cannot. As much as he would love to help, he knows as much about cursors and queries as the developer knows about the Gantt Charts.

Usually in these cases, the manager also misses an important queue: that the developer is seeking help.

The manager switches to the Gantt Chart mode and talks about how much more time the developer would need.

After a while the developer gets the rules of the game and he stops discussing technical issues with his manager. They try to talk the language of the Gantt Chart, except of course, there is only one problem: Developers suck at speaking that language, specially when it involves saying no.

A disconnect begins.

Very soon, the performance of a developer who was otherwise thriving, takes a steep hard nosedive.

The post is not about criticizing managers or developers. I also don't have a recipe for success here. The only advice I can leave you with, if you are managing a team of developers, is, look for slightest of signs when your developers need help and when you notice that they need help, help them. If you cannot help them because you are not technical enough don't hesitate walking up to anyone in the organization who can genuinely help and ask for it.

Until you do that, chances are, that the nested queries will not automatically speed up by the end of the week.

The story of NewsTilt and why the young startup nosedived its way into failure and eventually shut down sends a chill down your spine as you read it.

As you read the post which describes one of the founder's view of why the organization failed, you start reading between the lines and you start finding dark gaps which give you a glimpse into what the real reason for NewsTilt's failing might have been. Embedded between the lines of the posts you find chilling comments passed with an innocent, matter of fact tone which make them all the more scary. For example, Paul (one of the founders of News Tilt) explains:

Since we needed to build so quickly, as soon as we got some money we wanted to hire another technical person. Nathan had a friend he wanted to hire, who was exactly the kind of great programmer he could work well with. However, it took some convincing to get him to try working on a news website, and he wasn’t sure he’d stick with it. We were sure we’d be able to convince him to stay, and we even waited two weeks for him to move to work with us.

Unfortunately, we were never able to excite him about the project, and we quickly realized he was never going to be intrinsically motivated the way we need for a first employee. There was a point when I was over in Cambridge with Nathan and the other developer, and I noticed that the developer wasn’t working on a Sunday. Now, we aren’t the kind of people who think our employees owe us 90 hours a week, but startups need that kind of work ethic from very early employees–exactly the reason that intrinsic motivation is so important. If your first employee doesn’t love what you do, doesn’t wake up each morning dying to work on HIS product, you have likely chosen poorly, and that’s exactly what we did.

As you skim through the article you begin to understand that the problem with NewsTilt wasn't any of the reasons mentioned in the post. The problem with NewsTilt probably was the fact that the founder believed that by jumping into an unknown domain and hiring idiots who work ninety hours week can make you a shitload of money. Take for instance this quote from the post:

Somewhat surprisingly, the journalists we picked were too good. We made a big deal of only hiring the “best journalists”, something we spent a great deal of time getting right. We had a guy with a Pulitzer, one with an Emmy, and overall a great deal of talent writing for us [3].

In hindsight, this may have been a big mistake. The kind of writer we actually needed was one that was hungry to succeed. Someone who would write five pieces a day, and who wanted nothing more than to be a big-time journalist. We needed a young Perez Hilton or Michael Arrington, people who wrote for 18 hours a day in order to make their names.

Instead, we got journalists who were already successful in their day jobs, and who already had families and other commitments.

Not to mention of course that these journalists were working for free. If this post does one thing, it bring out NewsTilt as a company which expected everyone, their employees and their journalists, to sacrifice their personal life and give in eighteen hours a day behind an idea and a domain that the founders themselves did not know anything about.

Paul explains why his idea was great and that Google could have made it work:

Google could have made this work. I believe that if Google applied the same model they could probably succeed. They have the tech ability, they have the traffic, and they already have a massive news property. They also have have a big problem with whiny news organization, and an elegant solution would be to kill them off by enfranchising their journalists to be their own bosses.

Of course Google could have made it work. But then again, Google is okay with giving twenty percent personal time from their normal five day work weeks to their developers, leave aside expecting them to work Sundays. Besides, Google is also not pointing fingers at their developers for not working weekends when their products fail. Not to mention that most successful developers work less and say no to meaningless slogging.

Let's face it. NewsTilt probably failed because of a lousy founder who wanted people to stop having a life and work ninety hours a week for an idea that he himself did not know deeply.

The entire post runs into pages and by the time you are done with reading it you realize that Paul could have done a way better job with the post by just saying  "I fu@#ked up. I am sorry". It would have been way better than whining about the developer not working weekends and the journalists having families. But then again, saying "I fu@#ked up" is hard.

Besides, realizing how bad you are at something requires the same skills that you need to become good at that thing.

Paul as a founder has a terrible blind spot that most readers of that post can see rather easily.

Go on. Read the chilling story of NewsTilt and it's failure and as you read it be sure to read between the lines and learn exactly the kind of attitude you should avoid while leading an organization, startup, business or even your small team at work. That and when you make mistakes, stop pointing fingers at others and accept the fact that it was you who fu@#ked up. After all, it is always your fault. Seriously.

The topic of a recent discussion that I got into revolved around what made 37Signals, 37Signals to begin with.

Was it their life style?

Was it their methodology?

Was it the fact that they were small?

Was it their book, Getting Real?

The opinion that emerged out of the discussion was that the answer was none of these. What made 37Signal, 37Signals is that they contributed true value in the form of Ruby On Rails, then Basecamp and then truckload of other products.

Ideas are a dime a dozen. Anyone can start a blog and talk at length about how amazing product management should be done.

Of course, anyone does not include the millions of 501 programmers, who cannot even program or muster enough motivation to lurk at a blog or own a book on programming, leave aside writing one, but well, anyone with enough motivation, some basic writing skills and some imagination can talk about software development and do blog posts on wisdom gained from doing years of software development.

If you do not have years of experience in software development, you can talk about social media and pull numbers straight out of your ass and impress people. Or better still, you can just quote numbers others have pulled out of their ass and act smart and knowledgeable.

If even that does not do it for you, talking about Entrepreneurship and how you will run your company when you start it up might do the trick.

Preaching, is easy.

Don't get me wrong. Sharing of ideas and experiences is what this blog has been about since its inception and we need some inspiration and sharing of ideas from time to time. It keeps our creative spirits alive. But too much inspiration can be addictive.

When you find yourself taking shots of inspiration morning, afternoon and evening. When you find yourself seated in meetings about entrepreneurship once every week, you know that you are just talking. Participating in a discussion, even at a world wide scale is good but do too much of it and you get a little sick and tired of it. There are times, when after years of blogging, you look back at your blog and you question if the value that you have added is adequate.

Yes you contributed a few innovative ideas, you sparked a few interesting discussions and you rocked on Reddit a couple of times but are ideas, thoughts and discussions all you can contribute? What about real value? What about a real product? What about discussing real code?

Somewhere months ago I asked myself this question and started Code Persona, my little corner where I document my development experiences. The site of course did not take off primarily because of lack of content.

Within weeks of starting the website it was rather evident that I might be decently acceptable at writing code (who needs talent when you have intensity) my ADHD makes it nearly impossible for me to write technical posts on the web much like I find it difficult to be reading from a physical book all the time.

But recently the desire to add genuine, concrete, value has been driving me nuts. In short, I have done enough of preaching and while I love sharing ideas here, which I will continue to do as frequently as I have been doing, I also really want to get out there and discuss something concrete. Like, say, code for example.

Without going into specifics, lets just say that it was simple divine intervention, that prompted me to grab a microphone and headset that had been sitting on my desk only to get used occasionally for boring conference calls, to start recording a series of videos on Microsoft Entity Framework.

The thousandtyone youtube channel was born.

This is 'not' going to be about thoughts on management, this is not going to be about discussion on process and hopefully this is not going to be about countless arguments on what is right and what is wrong.

This is going to be the IDE and code. We start with a series of videos on Entity Framework and from there every week we will dive into anything and everything that seems interesting. I spend a good part of my day breathing, writing, reading, eating, drinking and thinking about code. It is high time I start contributing something through it.

Like I said, the first series of about five to six videos is going to begin with Entity Framework but from there, we are going to jump into anything that seems interesting. Object Orientation, Inversion of Control, Test Driven Development. If it seems interesting, we might end up doing a quick fifteen minute video on it. If the video does not cover everything that had to be said on the topic, expect the video to turn into a series of videos.

Also expect to see a video series on Getting Started With Programming. I know quite a few business analysts, testers and managers who can benefit from that. Besides, the real motive behind that series is going to be teaching my young eight year old nephew how to write code.

The YouTube format of fifteen minute videos works perfectly for someone with ADHD like me. Besides you can chose to skip the videos, rewind them if you do not understand them or play them at triple speed if you believe we are moving along too slow.

Long story short, here is the thousandtyone youtube channel. We are going to write code on the record mode, we are going to learn how to write better code, we are going to teach you how to write better code and we are going to do that rather often. Hopefully, every week.

Code Persona will get updated every time a video gets published on the channel so if you are subscribed to it, you should get notified every time a new video hits the thousandtyone youtube channel.

Basically, it's like this. I spent all these years talking about good programmers and good programming. Here is your opportunity to see me writing code and tell me how much I suck at it. You are not going to miss that opportunity, are you? #Grins.

Go ahead, hit the channel, take a look at the first video and subscribe to it if you are interested in being a part of it.