If you have ever worked on anything that was used by more than one user, for more than a few days of their lives, you probably get a truck load of hugely random and weird feature requests at work. If you have worked with a bunch of marketing and sales folks responsible for demoing your product to 'potential customers' you probably know this even better. 

I have talked about avoiding the Perils of Demo Driven Development through heavy use of YAGNI before. But then having said that, every once in a while, a random critic will convince your marketing and sales team that if you could just build that chat application that allowed the point-of-sales team to interact with each other and integrate it with your billing system your billing system will sell like hotcakes.

If you have ever thought of giving in to temptation and building stuff that the competition is building just so that your product could compete with your competition, Paul Buchheit of Gmail has sensible word of advice for you. He explains:

I believe this "more features = better" mindset is at the root of the misjudgment, and is also the reason why so many otherwise smart people are bad at product design (e.g. most open source projects). If a MacBook with OSX and no keyboard were really the right product, then Microsoft would have already succeeded with their tablet computer years ago. Copying the mistakes of a failed product isn't a great formula for success.

What's the right approach to new products? Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product -- the rest is noise. For example, the original iPod was: 1) small enough to fit in your pocket, 2) had enough storage to hold many hours of music and 3) easy to sync with your Mac (most hardware companies can't make software, so I bet the others got this wrong). That's it -- no wireless, no ability to edit playlists on the device, no support for Ogg -- nothing but the essentials, well executed.

We took a similar approach when launching Gmail. It was fast, stored all of your email (back when 4MB quotas were the norm), and had an innovative interface based on conversations and search. The secondary and tertiary features were minimal or absent. There was no "rich text" composer. The original address book was implemented in two days and did almost nothing (the engineer doing the work originally wanted to spend five days on it, but I talked him down to two since I never use that feature anyway). Of course those other features can be added or improved later on (and Gmail has certainly improved a lot since launch), but if the basic product isn't compelling, adding more features won't save it.

On his assessment on whether iPad is a great product or not, or if all the critics shouting at the top of their voice about the lack of features in the iPad are justified in doing so or not, Paul gives useful advice to young and budding product designers. He explains:

By focusing on only a few core features in the first version, you are forced to find the true essence and value of the product. If your product needs "everything" in order to be good, then it's probably not very innovative (though it might be a nice upgrade to an existing product). Put another way, if your product is great, it doesn't need to be good.

Making the iPad successful is Apple's problem though, not yours. If you're creating a new product, what are the three (or fewer) key features that will make it so great that you can cut or half-ass everything else? Are you focusing at least 80% of your effort on getting those three things right?

If you are working on a product, go ahead. Pick those three small and simple things which your product is supposed to achieve. Write them down in easy to understand sentences on a whiteboard.  Now, do some serious soul searching on if your product does these three things flawlessly. Is your product the best in the world at doing these three things? With consistent effort and hard work, can it become the best in the world at doing these three things?

If you answered no, adding features to your product will not help. If you answered yes, put in that consistent effort and hard work to make your product a great product, because if it is a great product, you won't have to slog your ass to make it a good product.

I wish you good luck.

During my work at a client, who for the purposes of this post, I shall refer to as Multiplitaxion Inc, I saw an amazing example of management and HR policies, backfiring in ways that no-one had expected them to backfire.

Multiplitaxion Inc, was an amazing place to work at. Even for me as an outsider or a consultant who was just visiting, the folks at Multiplitaxion Inc were not just nice, they were super nice. They got me my very own personal cabin, gave me printer access and even had a name plate with my name printed even though I was just going to work with them for a few months.

Multiplitaxion Inc, happened to be one of those places where a group of like minded people gather, not just to work but to live a like minded life. These were bunch of rather amazing oil engineers and software engineers who worked for twelve to thirteen hours a day. Walk into Multiplitaxion Inc at seven in the evening and chances were that you would see a bunch of engineers flocked together trying to solve a problem.

During my stay at Multiplitaxion Inc one thing I noticed was that people hardly ever took leaves. During my first three months of stay, no-one from my team ever took a leave. 

This story however, begins on a bright sunny day when someone high up in the pecking order who had access to the time card logs and no real work to do decided to glean though the logs and discovered that people were coming really late to office. Soon strings were pulled and decisions were taken for the best interest of the organization.

Emails went out informing the employees that folks entering office after ten would be marked absent for the day and that people were 'requested' to be at office on time. A policy that was supposed to put some sense into office timings and increase employee productivity. A policy that started backfiring on the very first week on which it was imposed.

Turns out, Jack, who happened to be one of the youngest and the brightest programmers in our team, stumbled on a scenario which caused the policy to backfire on the very week in which when it was imposed. One first morning, as Jack prepared to leave from office, his eyes fell on the watch and seeing that it was nine-thirty already, Jack realized that there was no way he was going to cover a one hour drive and make it to office by around ten. 

Jack, gave the situation due thought and given the fact that he had a ton of leaves cumulated with him because he never took any, decided to go for the idea of taking the day off. From that point on, the idea spread like wildfire. Folks who had never taken leaves in years, suddenly started going missing. Passion that had once driven folks to come to office, turned into confirmation towards rules. Leaves that were never utilized were now used up rather quickly.

A policy that was designed to make people spend more hours at the workplace turned into a policy that made them spend the least number of hours that they had spent in office during their entire careers.

What had happened here is very articulately describes by Dan Ariely in his book Predictably Irrational. Dan explains:

My good friends Uri Gneezy (a professor at the University of California at San Diego) and Aldo Rustichini (a professor at the University of Minnesota) provided a very clever test of the long-term effects of a switch from social to market norms. A few years ago, they studied a day care center in Israel to determine whether imposing a fine on parents who arrived late to pick up their children was a useful deterrent.

Uri and  Aldo concluded that the fine didn't work well, and in fact it had long-term negative effects. Why? Before the fine was introduced, the teachers and parents had a social contract, with social norms about being late.

Thus, if parents were late—as they occasionally were—they felt guilty about it—and their guilt compelled them to be more prompt in picking up their kids in the future. (In Israel, guilt seems to be an effective way to get compliance.) But once the fine was imposed, the day care center had inadvertently replaced the social norms with market norms.

Now that the parents were paying for their tardiness, they interpreted the situation in terms of market norms. In other words, since they were being fined, they could decide for themselves whether to be late or not, and they frequently chose to be late. Needless to say, this was not what the day care center intended.

In the same book Dan goes deeper into the concept of why this fine did not work using the idea of two worlds that each one of us live in. He explains:

As Margaret Clark, Judson Mills, and Alan Fiske suggested a long time ago, the answer is that we live simultaneously in two different worlds one where social norms prevail, and the other where market norms make the rules. The social norms include the friendly requests that people make of one another. Could you help me move this couch? Could you help me change this tire? Social norms are wrapped up in our social nature and our need for community.

They are usually warm and fuzzy. Instant paybacks are not required: you may help move your neighbor's couch, but this doesn't mean he has to come right over and move yours. It's like opening a door for someone: it provides pleasure for both of you, and reciprocity is not immediately required.

The second world, the one governed by market norms, is very different. There's nothing warm and fuzzy about it. The exchanges are sharp-edged: wages, prices, rents, interest, and costs-and-benefits.

Such market relationships are not necessarily evil or mean—in fact, they also include self-reliance, inventiveness, and individualism—but they do imply comparable benefits and prompt payments. When you are in the domain of market norms, you get what you pay for—that's just the way it is.

Dan holds the opinion that when you take a social norm and try to replace it with a market norm you typically, for lack of a better word, f@#ck things up. He explains this much more articulately that I would be able to describe it, using what happened with the fining incident in Israel:

But the Real story only started here. The most interesting part occurred a few weeks later, when the day care center removed the fine. Now the center was back to the social norm. Would the parents also return to the social norm? Would their guilt return as well?

Not at all. Once the fine was removed, the behavior of the parents didn't change. They continued to pick up their kids late. In fact, when the fine was removed, there was a slight increase in the number of tardy pickups (after all, both the social norms and the fine had been removed).

This experiment illustrates an unfortunate fact: when a social norm collides with a market norm, the social norm goes away for a long time. In other words, social relationships are not easy to reestablish. Once the bloom is off the rose—once a social norm is trumped by a market norm—it will rarely return.

For the passionate software and rig engineers who worked at Multiplitaxion Inc, coming to office in the morning and working passionately for problems that were thrown their way was a social norm. What the time-policy at Multiplitaxion Inc did, was to take the social norm and mix market elements to it.

What Multiplitaxion Inc did with this policy, in the words of the book was much like, paying your mother-in-law for a fantastic thanksgiving party or for that matter paying your wife for her love.

Mixing social and market norms usually creates odd situations for everyone involved. If you lead a team or run an organization, it is hugely important that you realize the social norms that exist within your organization. There are things that people might be doing as a part of their existence in the 'social world' and the moment you try to reward or punish them using market norms, you are likely to create awkward situations and policies that backfire in ways you never thought.

Go ahead, use social norms heavily in your organization and when they are in place, don't ever try to replace them with market norms, because if you do, you just might f@#ck things up.

I love writing on this blog. For me this blog is more of an opportunity to stand back, evaluate the experiences of my life and write about these, by adding a little bit of myself to this blog. The very fact that I post multiple times a week, turns this blog into something which allows me to exercise my writing skills and develop my writing mussels.

Having said that, this post has developed a very different audience than what I initially expected. Besides programmers, this blog is read by managers, business folks and even my mom. One of the thing that I try to pay special attention to, while writing, is the timelessness of each post.

I try to add content here which usually does not tend to become obsolete when the next version of visual studio comes out. Of course, there are one or two  exceptions, but then, most of it happens to be timeless. At-least I try to make it timeless to the best of my ability, even though when I read my older posts, I do realize how much I sucked.

Because this blog is read my more than one reader, it often means that I end up spending a lot of time adding graphics, hyper linking, formatting and proof reading all content that goes out here.

To be honest, I love doing all of that.

A huge part of my life includes working with other human beings and that is what this blog is all about.

But then, there is another part of my life. A different persona, so to say. One that deals with bytes. One that likes to fiddle with technology, explain design patterns using wild examples and whacky home made philosophies and the one that likes to tinker with the code-base of crux in my free time.

Unlike most software developers, I have been fairly open about my experiences with other developers or what I learn from these experiences but then unlike most developers who write blogs, my close encounters with code and technology often remain undocumented.

The idea is not new however. I have been thinking about this for a long time. The whole concept of learning like a teacher and teaching like a student is something that I have talked about before on this blog.

I think it is time when I can introduce a different part of my personality on a different blog all-together.

People, here is presenting, my code-persona.

Think of code persona as my personal little wall to scribble things on as I work. Just bought a new cam-coder, you might read a review that I slapped together rather quickly there. If I just learnt a neat way to solve a programming problem, you might read it on code persona. The posts on code persona might not be as well formatted or as minutely proof read as this blog, but that's the whole point. Like I said, its my personal little wall.

So What Happens To This Blog?

Nothing. It continues. Just as before.

I am not stopping to write on this blog.

This blog will continue to have posts added to it, just like before.

So if you like the kind of content that you read here, you will continue to find more of it. But if you are a hardcore programmer and you are more interested in curly brackets and semi-colons, code-persona is the blog you also want to subscribe to.

It's been quite some time since I did some serious hardcore technical blogging.

I feel like a little child again and that, I believe is a really good thing.

Feel free to hang out with us on code-persona.

More content will start getting added there soon.

Wish me good luck.

My team at Multiplitaxion Inc, happens to be a group of really seriously kick-ass programmers where even some of the weakest in the team can kick some serious butt. Fred clears multiple rounds of interviews for Multiplitaxion Inc, and wants to join this team.

I cringe.

As far as I am concerned, if you are joining my team, I prefer that you have, either gone through my interview and met my criteria or have proved yourself within the organization in one way or the other before you are made a part of my core team.

Fred as it turns out, has done neither.

He is a young and budding programmer fresh out of college who has taken an engineering degree, answered a few math questions and a few puzzles correctly and cleared the Multiplitaxion Inc, interview with flying colors.

A few mails back and forth, the really awesome folks at the Human Resources department Multiplitaxion Inc, allow me to screen the guy and they give me the liberty of taking him in my team or letting him move over to a different team.

I spend some time talking to Fred, asking him a simple question - We have a month to build anything that you want to build. Can you spend a day thinking about what you want to work on and let me know tomorrow. We will start working on whatever you pick and I'll help you as we move on. After a month we will evaluate what we have built and if it's good enough you join the team.

Fred looks at me like I just dropped a rodent on the table.

The next day he comes back with three things that he would like to work on:

1. A brand new operating system - which is what you often fantasize about building when you are in an engineering college and if you are lucky they even let you build a small theoretical kernel as your college project.
2. A brand new security algorithm - again a hugely academic project I am sure a million mediocre students in a million colleges around the world are working on.
3. A Patient tracking system for a hospital - this one, I'd rather not comment on, for the fear of sounding very nasty and mean.

Then Fred basically tells me that even though he has thought of these, he is not going to actually work on any of these. Put simply he is not up for this whole lets-innovate-idea. He wants an assignment and he wants to start working on it right away.

On any given day I get bombarded with dozens of ideas which I tend to put on the back-burner till they find me, grab me by my collar and make me work on turning them into realities. In our days, we became programmers, because it was fun and because it was empowering. It allowed you to think of stuff you could build and turn this stuff into reality.

I see, talk and work with countless programmers around the world and while the niche still gets it, I think, overall we are just breeding 501 programmers who join the software business because its good money or because their friends are joining it. Of all the things that young and budding programmers coming fresh out of college these days tend to lack, is the ability to find their own sources of motivation.

We are screwing the software development world and letting it loop in the infinite loop of failure by turning it into factories where clones are produced. If you are reading this and are responsible for hiring folks in your organization, might I suggest that you turn this into an interview question.

Ask a candidate what he would build if he was given one month of free time to work on anything that he wanted to work on. His reply may or may not impress you, but it will tell you a lot about why he wants the job. Now make an objective decision on if you really want him on your team.

Go hire programmers who can drive themselves rather than folks who want to be driven like a folk of sheep.

I wish you good luck.

Most managers typically go through the periodic phase of being an asshole. Its the time when you play the blame game. Its typically the time when you forget that you are not getting paid to screw people left and right.

The difference between a-fun-to-work-with-person and a prick is that while the prick never snaps out of that adolescent stage of being an asshole, the fun to work with manager often gets sick of it, disconnects and learns from those times. He looks back at those times of his life as painful moments and treasures everything that he learnt during the conversion phase.

He probably has a Not-To-Do list for himself which is bigger than a to do list for his team.

He is serious about the idea of being nice at workplace.

I call these folks, converted assholes.

Now, a truckload of things might have caused the conversion to happen, starting from a tragedy to just finding a pet, but a guy who was once an asshole and is now raging a war against the idea of prickdom at workplaces, is invaluable for your organization.

This is the guy who understands how prickdom works inside out.

This is the guy who can smell prickdom from miles and can spot an asshole in an interview.

This is the guy who can identify assholes in your organization.

This is the guy who can give the assholes in your organization a hard time. Sedate the monkeys. Confuse the jargon idiots with more random jargons. Attend meetings and sit through them without dozing, guarding the ground from folks pooping on your organization or team through funny decisions that are usually taken in these meetings under the name of 'working for the best interest of the organization'.

Put simply, he knows how the game is played, he plays it well and can be a bigger prick when dealing with pricks in your organization.

If you are a young and budding entrepreneur looking to have a kick-ass environment at your workplace, go hire a few converted assholes and get them to rage a war against prickdom within your organization.

I wish you good luck.

I have always nudged young and budding developers to try and turn themselves into one man armies. I have also often gone ahead and said that a good programmer is formed when, as they say in martial arts, the warrior and the weapon become one.

In a recent conversation with a young and budding programmer regarding how most office environments are nothing more than cubical farms for breeding incompetence, I stuck to my point, that most awesome programmers who know what they are doing will figure out ways to communicate and collaborate without needing a common physical location.

They will find quite islands, homes, cafeterias and corners of the world to work from. They will continue to thrive even as more and more loud or lousy workplaces continue to get built around the world.

The seriously kickass programmers will turn into one man armies and software cells that can function from anywhere and anytime. They will carry their weapons and most importantly they will carry their ability to become one with their weapons anywhere and anytime.

The Dell Mini 9, was given to me by eFORCE to try out when Netbooks first came out. I have had this thing for more than a year now and my assessment of it is that this is one rather peculiar weapon in the hands of a developer.

When I say that the Dell mini 9 is a very different kind a weapon, what I really mean by that, is that Net-books by their very nature, screen size and keyboard layout are a very different kind of a weapon in the hands of a developer.

To begin with they tend to make any developer worth his salt get a serious headache when you try to work on them. After a while, you start questioning the whole idea of working on a tiny oddly laid out keyboard and a tiny screen.

It is purely because of this peculiar nature of these devices that the Dell Mini 9 practically sat unused for months lying at my home.

I would occasionally use it to load and work on Ubuntu, but as far as practically using the device was concerned, I would cringe at the very thought of typing at the small keyboard and staring at the small screen.

I used it so little I even managed to lose its power cable.

It was not until recently that the idea of being able to work from anywhere and harnessing the power of mobility started getting discussed, that I thought I'd give the Netbooks another shot. The idea was to get a new internet access data card and use the Netbook to work from anywhere.

Today is about my first day of seriously trying to work on the Netbook and things aren't really as bad as I had expected them to be. For starters, I am getting used to working long hours on the smaller screen and the headaches are starting to disappear rather rapidly. In fact, I am no longer experiencing those headaches and bouts of irritation anymore.

The keyboard layout on this thing is slightly weird, but then I am getting used to it rather fast as well.

I have a Window 7 Ultimate loaded on this thing, along with a couple of image editing software, windows live writer, Microsoft office and a text to speech converter so that I can proof read my blog posts.

This would be my second post from the Mini 9 and as strange as it might seem, I am becoming one with this tiny weapon that lay unused at my home for months.

On the work side, I tried remoting into a office machine and tried writing some code on the remote box. It was not as bad as I had expected either. It's definitely not the only machine you would like to have, but then, it is a very different kind of a weapon for a very different kind of an attack that every software programmer must learn.

One major gripe I have with this machine, specially while programming is the position of the double-quote and a couple of other keys on the keyboard. Having said that, a little bit of practice and I think I might be able to get over these annoyances.

The funny thing about these devices, specially if you can tune yourself to become one with them and use them productively is that you can exploit the heck out of them. For once, you could be writing code on a remote box located at a data center in California as you drive through the plush green pastures of India on a  weekend vacation.

No fear of denting an expensive laptop. No worries of wearing off the battery because of excessive use. Toss it in your bag, carry it everywhere with you, exploit the heck out of it and get work done like never before, from anywhere, anytime.

Go learn the art of mastering tiny weapons, tune yourself to them and become much more productive.

I wish you good luck.

On a side note, for a detailed technical review of Dell Mini 9, see Scott Hanselman's post on the review of the device. I consider Scott to be a rather worthy maven of the software development world and his post on Dell Mini 9, to an extent, nudged me to try out my Dell Mini 9 again rather than letting it gather dust. I am happy it did.

I will continue to post updates if my opinion on Netbooks changes again but for now, I am loving the idea of being able to carry these devices anywhere and doing some serious damage using them. What is your experience with Netbooks?

Discuss.

We are seated at a local startup club where startups demonstrate their products to a bunch of fellow developers, designers, entrepreneurs or technologists. An young man is talking about his idea of building a community site with a difference. He wants to build a community site for runners and walkers around the world.

He doesn’t have a thing to show us.

No wireframes. No screens. No working systems. Absolutely nothing.

He seems to be blabbering non-stop about how his idea is different and how no website in the world has thought about it before him. It almost seems like he has just hit upon a totally different and new way to fly the skies.

During a quick bathroom break we start talking to this gentleman and I mildly and politely hint to him that maybe, just maybe, everything that he is trying to build on his community website can be easily done with a Facebook community site.

He seems grossly offended.

Somewhere, unknowingly I seemed to have shattered his dream and told him what he really does not want to hear.

Its not his fault though. Most ideas are a dime a dozen. To make things worst, when its your idea you tend to think that its the best thing since slice bread. You tend to protect your ideas like babies when your all your ideas need is dedication and concrete work, not protection.

Go on. Take the litmus test. Think of an idea. Then try to find websites that do exactly what you just though about. Chances are that you will stumble upon at-least a dozen sites that do exactly what you were just thinking about.

There is also a high possibility that when you stumble upon these websites, you will disregard them as useless and you will start sentences which begin with – "yes but this website is slightly different than what I was thinking about. It does not do 'Z' which is what is going to differentiate us from them.

Newsflash.

Your idea is already taken. Someone beat you to it and you have no unique selling points. You are just making this differentiation crap up because your brain has just switched to a denial mode where it is clearly refusing to accept that someone beat you to that idea, executed the entire idea flawlessly and is making money from the idea.

You, were late.

Deal with it.

Your product idea just does not have a unique selling point.

All that yes-but-we-are-different talk that you are mumbling is just bullshit to feed your own ego and pamper it.

You have about a dozen competitors out there and the only thing that is going to set you apart is how you add a little bit of yourself to the product and how you handle execution.

Now, take a pause. Reflect. Ask yourself if you can genuinely pull off an execution that is superior than any of the other products out there. Be careful, because even here, your brain is going to trick you into saying, 'Sure! Of course I can!' without giving it any real thought in the first place.

Take your own sweet time. Reflect. If the answer is no and if the idea is not keeping you awake at night, it's okay let go shamelessly. After all, you do not find truly remarkable ideas. Truly remarkable ideas find you. It just makes the defeat that much more easier to accept and it frees your mind to find something else that really matters to you.

Go ahead, start something that makes a small dent in the universe or just give up and wait for a new idea but don't build a mediocre crappy product because we have enough of them already.

I wish you good luck.

One of my first teams kicked some serious butt. We shouted at each other, we used the F-word rather generously and when that did not work, we raised our volumes to a level that would blow the office roof sky high.

Then when the fight was over and the best solution had won, we would go out and have lunch together with no hard feelings.

That was my understanding of strong opinions and disagreement.

These were two very useful tools to reach the best of solutions. During my times at Multiplitaxion Inc, I often tended to respect guys who had strong opinions weekly held and had  the conviction or the spine to disagree with me.

Disagreement was loud.

Disagreement was a good idea-validation-check.

Disagreement was good.

It was only during the later part of my career that I bumped into a different form of disagreement that confused me and left me totally dumbfounded.

Ladies and gentleman, if you haven't met 'Silent Disagreement' you are one lucky son of a gun.

If you have, you know exactly what I am talking about.

This is a form of disagreement where someone sits smack across the table to you in a meeting, nods his head in agreement to everything you have to say and then goes out and does just the opposite.

Consider an arbitrary example for instance. Assume that everyone in  your organization, starting from the lowest programmer fresh out of college, all the way up to the chief-executive-officer agree on having a free open internet access policy.

You call the group who is responsible for maintaining the restrictions on firewall in a meeting where you tell them to drop all restrictions from non-work related sites like Facebook or You-Tube. You are going to trust your employees work ethics more than a firewall, you tell them.

Everyone nods in agreement.

You wait for the firewall policies to change and Facebook to get unblocked. Nothing happens. Days later someone higher up in the management sends a flame mail, asking that all sites be unblocked immediately, and everything gets unblocked, only to get re-blocked a couple of days later.

You call another meeting to discuss what went wrong here. Did we disagree on something? Did we not collectively decide that we were going to have an open internet policy? Did we not agree on that? Didn't we waste an entire day discussing the pros and cons on having free internet and trusting your employees versus blocking non-work-related sites?

Strangely enough, even in this meeting, everyone agrees to the idea of an open internet policy.

Strangely enough, non-work related site still remain locked down.

It is then that you realize, that you are not dealing with rational, thinking, objective individuals who believe in strong opinions weakly held. You are up against folks who take every argument personally, folks who indulge in strong flavors of mitigated speech and folks who do not express their disagreement in words but instead choose to disagree, silently.

During my career as a software developer I have seen countless examples of silent disagreements. I have seen examples of folks who think that they should say 'no' to their managers but who lack the spine to say 'no' to their managers on their face, so they resort to silent disagreement. I have also seen folks who think that they are working for the 'best interest of the organization' and use silent disagreement to avoid all arguments or discussions.

Assuming that you can bring about change in your organization, if there is just one thing that you can change, I suggest you put an instant stop to silent disagreement within your organization. This is another one of those issues that you are way better of confronting rather than avoiding.

Go on, confront the folks who tend to disagree silently, and demand an open objective argument or total agreement through not just words, but action.

I wish you good luck.