free html hit counter
Posted on: Thursday, July 9, 2009 by Rajiv Popat

Behind Every Failed Project Are Reasons That Are Simple And Straight Forward.

Microsoft Solutions Framework Essentials: Building Successful Technology Solutions - a book on Microsoft Solutions Framework (MSF)  by Michael S. V. Turner talks about the Standish Group 10th Annual (2003) CHAOS Report which mentions that only 34% of the projects in a sample size of 30,000 projects are successful. A staggering 51% are badly challenged --- the kind I like to call 'successful failures'.

To add to that 15% of them take a nose-dive to a down right catastrophic failure.

When I was doing a post on the fact that the success or failure of your project depends on the competence of your team and not other complicated factors like 'lack of a systematic process' one question that kept pinching me was why didn't project managers around the world just 'get it'. Why did they keep finding refuge in complicated terminology and jargons.

To find the real answer to the question; dear reader; you have to dive in the human mind and how it works. Besides the fact that complicated reasons give young and budding managers a curtain of crap to hide behind; I am also starting to believe that there is more to this phenomenon that just the prickdom of the young and budding managers or the desire of developers to save the skin of their other fellow developers.

Study how the human mind thinks or works and you'll find that there are two primary reasons why project failure analysis never produces any real concrete reasons for the project's failure.

The first one being; the fact that the human brain is often incapable of comprehending the implications small things can have on our lives and our projects. Malcolm Gladwell describes this phenomenon in his book - The Tipping Point - where he offers his readers a simple hypothetical puzzle:

Consider, for example, the following puzzle. I give you a large piece of paper, and I ask you to fold it over once, and then take that folded paper and fold it over again, and then again, and again, until you have refolded the original paper 50 times.

How tall do you think the final stack is going to be?

In answer to that question, most people will fold the sheet in their mind's eye, and guess that the pile would be as thick as a phone book or, if they're really courageous, they'll say that it would be as tall as a refrigerator.

But the real answer is that the height of the stack would approximate the distance to the sun. And if you folded it over one more time, the stack would be as high as the distance to the sun and back.

This is an example of what in mathematics is called a geometric progression.
As human beings we have a hard time with this kind of progression, because the end result — the effect — seems far out of proportion to the cause.

Bring this to the world of software development; and we often tend to miss out of the ramifications of slightly in-competent programmers in our teams or organizations. Anyone who reads legendary author Steve McConnell knows that a competent programmer is ten times more effective than an incompetent one.

Having one ass-hole or a monkey is enough to screw up your next project.

So; that lowering of the selection criteria during your interview process obviously has a impact which is large enough to cause your projects to go for a catastrophic nose-dive while your brain struggles to comprehend how relaxing the selection criteria in an interview 'slightly' can cause projects to fail.

The other part of the answer; lies in the fact that that human beings by their very nature are pathetic risk assessors. Steven D. Levitt and Stephen J. Dubner describe this problem much more articulately in their book Freakonomics. The explain this phenomenon using two simple examples. In the first example they site the example of deaths caused by having guns in home; vs. deaths caused by having swimming pools:

Consider the parents of an eight-year-old girl named, say, Molly. Her two best friends, Amy and Imani, each live nearby. Molly’s parents know that Amy’s parents keep a gun in their house, so they have forbidden Molly to play there. Instead, Molly spends a lot of time at Imani’s house, which has a swimming pool in the backyard. Molly’s parents feel good about having made such a smart choice to protect their daughter.

But according to the data, their choice isn’t smart at all. In a given year, there is one drowning of a child for every 11,000 residential pools in the United States. (In a country with 6 million pools, this means that roughly 550 children under the age of ten drown each year.) Meanwhile, there is 1 child killed by a gun for every 1 million plus guns. (In a country with an estimated 200 million guns, this means that roughly 175 children under ten die each year from guns.)

The likelihood of death by pool (1 in 11,000) versus death by gun (1 in 1 million-plus) isn't even close: Molly is roughly 100 times more likely to die in a swimming accident at Imani's house than in gunplay at Amy's. But most of us are, like Molly's parents, terrible risk assessors. Peter Sandman, a self-described "risk communications consultant” in  Princeton, New Jersey, made this point in early 2004 after a single case of mad-cow disease in the United States prompted an anti-beef frenzy.

"The basic reality," Sandman told the New York Times, "is that the risks that scare people and the risks that kill people are very different."

Bring the idea over to your project and evaluate what is more likely to kill your project; having incompetent assholes; no customer feedback and a thousand other really small things or lack of a 'formal communication plan and scope control document'.

Most so called traditional project managers around the world will give you hours worth of free lecture on why a Process (with a capital 'P') is vital to your project.

Why they do this can be best explained with the whole idea of perception of control called the 'control factor'; described rather articulately by Steven D. Levitt and Stephen J. Dubner  in Freaknomics. The book explains:

But fear best thrives in the present tense. That is why experts rely on it; in a world that is increasingly impatient with long-term processes, fear is a potent short-term play. Imagine that you are a government  official charged with procuring the funds to fight one of two proven killers: terrorist attacks and heart disease. Which cause do you think the members of Congress will open up the coffers for?

The likelihood of any given person being killed in a terrorist attack are infinitesimally smaller than the likelihood that the same person will clog up his arteries with fatty food and die of heart disease.

But a terrorist attack happens now; death by heart disease is some distant, quiet catastrophe. Terrorist acts lie beyond our control; french-fries do not. Just as important as the control factor is what Peter Sandman calls the dread factor. Death by terrorist attack (or mad-cow disease) is considered wholly dreadful; death by heart disease is, for some reason, not.

Obviously; the young and budding manager is more concerned about the 'Process' than he is concerned about 'hiring'. 'Change of Process' and 'Control' mechanisms happen now. Besides; the standard issues that most BDUF processes try to address are just an inherent part of software development. The chaos can hardly be eliminated.

Trying to do formalized 'Change Control' mechanism instead of embracing change and focusing on quality people; is much like trying to control terrorists when the French-fries of simple and subtle incompetence might be destroying your project right now as you read this.

Understanding the human mind has huge implications on how we run and manage our projects. Understanding three things when analyzing project failures is hugely critical:

  1. Our brain has a hard time relating to how small things; like lack of customer feedback; slightly lowered selection standards etc. can have huge impacts on the project.
  2. We are terrible risk assessors; what seems to be the most probable cause of failure for project to us; most probably; isn't.
  3. The 'control factor' can make you do stupid things and lose focus on the much bigger problems at hand.

Now; you can go there and spend thousands of man-hours and dollars defining a 'Process' (with a capital 'P'), a formal 'scope control' document, a formal 'change management' document, and a formal 'risk assessment plan' followed by a million other documents which make you feel in 'control' or you can hire a team of seriously kick ass programmers; set them lose and spend your time listening to your customers.

The complicated reasons why you were told your last project failed; probably aren't true.

With this post; all I am trying to do; dear reader; is suggest that maybe; just maybe; your project failed because of completely different reasons which were not as 'sexy'; not as 'urgent' and not has 'seemingly big' as 'A Formal Process'.

Now; you can get back to watching the CNN report on terrorism on Television as you munch on super-sized packet of french-fries and then when you get a heart attack go blame the terrorists. As absurd as that sounds; and as unlikely it is that you will do that in your real life; that is precisely what most managers do when it comes to project management.

I leave you; dear reader; with a thought worth harping on.

Go take a journey into the depths to time and try to figure out why; any project that you may have been a part of or you may have witnessed failing; failed.

This time; for a change; try to be completely honest to yourself.

Maybe the real reasons for the project failure were not all that complicated after all.

Remember - behind every failed project are reasons which are simple and straight forward; sometimes so simple that our brain has a hard time comprehending them.

posted on Thursday, July 9, 2009 11:46:24 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Tuesday, July 7, 2009 by Rajiv Popat

Avoiding Never Ending Arguments And Flame-Wars By Using (Twitter) Hash-Tags.

With only three visitors; my mom, me and you dear reader; this blog is a highly unlikely target for threats and intimidation. Having said that; what I often have a problem with; is the fact that; every now and then; I find myself defending my ideas from countless seemingly harmless attacks of Bozoism. The count of these isolated incidences seem to be slowly creeping up with every passing month.

While I completely believe in having strong opinions which are weekly held and the idea of having direct open arguments; it is when these arguments become completely illogical, baseless and turn into personal attacks; they start stressing you out emotionally.

Given all the incidents, emails, conversations, discussions and a few flame-wars that I've witnessed in the last one month I think it's time to wear the gloves and take up a stance that is both defensive and aggressive when it comes to the ideas and opinions expressed on this blog.

This post is about building a few of these psychological constructs that allow me to take that aggressive stance but then switch over to a defensive mode and escape without getting burnt when the flame-wars begin.

Acts Of Bozoism

When I started this blog; and started writing about my thoughts on software development; the idea was to turn my personal experiences and random thoughts into a coherent stream of ideas that others can connect to.

Doing that; has been fun.

It has taught me more than I ever hoped to learn and introduced me to a small number of really smart people I feel lucky to have known. The very start of this blog is an interesting story of me meeting and interacting with a bunch of really smart programmers; that I would have never had the opportunity to work with otherwise. I should probably do a separate post on that story sometime later.

To be honest; the tiny little blog with a small readership; has even brought me professional opportunities which I humbly and politely turned down. This was something I hardly expected could happen. Even though I write for none of these benefits; getting these as a free bonus has been a fun experience overall.

Having said that; lately; I've also started realizing that the act of turning your ideas into something that you can ship out to the world; gives any anonymous bozo out there the right to email you and pass random judgments on not just your work; but your thought process and even your way of life.

This post is supposed to give me some psychological constructs to dodge these random acts of Bozoism.

The Argument Continues

Besides the random acts of Bozoism; another form of argument that I am starting to have serious questions on; is the perfectly-logical-but-never-ending-type.

This is the kind where someone starts a discussion around a seamlessly harmless topic like:

'Hey Pops; do you think we should have detailed project plan for our project?'.

That's when you explain how utterly meaningless and over-rated the whole idea of project-plans is.

'Yes; but you know; this project is different; it's huge; we're building an enterprise system.' --- you are told.

Yes; we've all seen that horse-shit before.

You try to explain that; but it hardly helps.

It just results in another 'Yes-but' argument.

Now; don't get me wrong; there is absolutely nothing wrong with 'Yes-But' discussions. It is just that; when they cross thirty emails back and forth; or five hours of conversation in a cafe; without any clear indicating of coming to an end that they start stressing you out; mentally and emotionally.

You want to help the other person. You want to influence him; which is why you decided to participate in the discussion in the first place.

Having said that; it's when the 'Yes-But' discussions start stressing you out and you find yourself defending your ideas; you realize; that maybe the other person wasn't looking for help. Maybe he was looking for confirmation of his own ideas. This is when you realize that; maybe his ideas mean to him what your ideas mean to you.

That's when you realize that maybe; having a formal Microsoft Project Plan is as important to him as having kick ass developers in your team is important to you.

He is just not ready to throw his project plan out of the window yet.

Put simply; that's when you realize that maybe this isn't just a friendly battle of really strong opinions weekly held; it's a completely different thought process; a different core value or totally different way of life.

When this happens you want to give the person due respect for having a different opinion; wish him luck with his thought process and find an escape route to get out without getting burnt mentally or emotionally.

Besides the random acts of Bozoism; this post is supposed to give me some psychological constructs to end the 'Yes-But' arguments which otherwise have a tendency to continue and end up causing everyone involved a lot of stress.

Twitter Tags To The Rescue.

For all those of you who have been watching my twitter account (@Thousandtyone) activity; I am clearly becoming much more alive and involved at twitter. One thing I find really amusing about twitter is the whole idea of Twitter-Hash-Tags.

The whole embedding of Hash-Tags in Hundred-And-Forty characters is such an amusing idea that we would all be so much happier if; besides using it in twitter; we used the same approach in our lives.

Going forward; dear reader; I would like to propose the use of a few Hash-Tags which I will be using in verbal discussions; emails; twitter and sometimes even comments of this blog.

Put simply; these tags are supposed to provide you ammunition against random acts of Bozoism and Yes-But arguments and allow you to dodge them peacefully without get burnt in a flame-war. 

Lets talk about these tags.

End Of Bozoism - #EOB

If you find this tag embedded in an email; a comment or a twitter message that I send to you; this is my humble way to tell you that I think the argument is turning into a personal attack or a flame-war and that I am pulling out.

When this happens; you are free to continue to flame me; however; you will not hear back from me on the topic.

As far as I am concerned; even if I have arguments to present and more logical thoughts to discuss --- I am done.

End Of Argument - #EOA

If you find me embedding this tag in an email; a comment or a twitter discussion this is my humble way of telling you that the discussion is perfectly logical and that I am loving the ideas and opinions presented.

Having said that; I do not agree with them.

Yes; I do have some more logical arguments; but If you disagree with my ideas with points presented so far; it is highly unlikely that presenting more logical arguments will help.

The discussion has turned into a Never-Ending-Yes-But-Discussion where both of us seem to have not just different opinions but a completely different thought process or completely different set of core values and continuing the discussion on this topic; in all probabilities will not bring us to a conclusion.

I respect your ideas and I hope you respect mine.

You are free to continue the discussion and present more of your ideas but you will not be hearing from me on this discussion even if I may be tempted to present just one more 'Yes-But' argument from my side.

When I include this tag; I'm just saying; as far as this discussion is concerned --- I am done.


Alternately; I will also be using the End-Of-Yes-But-Discussion (#EOYBD) which means the same thing.

The Real Intent of These Hash-Tags

While #EOB, #EOA or #EOYBD sound rude the very first time you hear them; but I assure you dear reader; they are not. The intention here is not to prove that the other person is wrong; or too stupid to argue with. The intention is to give him due respect for this thoughts; acknowledge that there is a difference of opinion on one topic; that we can let the difference of opinion stay and get along really well by talking about other areas where we tend to agree more.

You're Welcome To Use Them Too

Going forward; every time I see myself getting into a argument that seems to be going nowhere or when the situation demands; I might be using these tags. You; dear reader; are free to use them too.

I am hoping that these tags allow you to hugely lower the need that you feel to indulge in discussions and arguments; specially when they become emotionally stressful; mentally tiring or seem to be having no definite end.

Go ahead; fell free to use them in your e-mails; twitter discussions; blog comments and any other arguments from which you want to back out; and quit by wishing others 'Best-Of-Luck'.

Go use them and have a stress free online existence.

I wish you good luck and just in case; if you do not agree with the whole idea of creating these twitter hash-tags; here is all I can say:



I wish you good luck.

posted on Tuesday, July 7, 2009 10:14:05 PM UTC by Rajiv Popat  #    Comments [3]
Posted on: Friday, July 3, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 3.

Screen And Pick People For Your Team Like Your Professional Life Depends On It.

A very senior manager at Multiplitaxion Inc, has picked a few candidates from the cream colleges out there based on IQ tests and Math questions. He expects me to on-board them on my team and begin their training.

I am looking at his condescending eyes as I speak the unspeakable - "I'll need to interview them again before they join my team. Not all will qualify."

Suddenly I find myself involved in an argument where I'm being asked if I feel that the selection criteria of Multiplitaxion Inc isn't good enough.

Breathe --- I tell myself.

My professional career as a manager at Multiplitaxion Inc, depends on who works on my team and who doesn't.

This is one thing where intimidation and pressure techniques will not work easily. 

No-one is joining my team; not till they give another interview and pass the team's selection criteria. Not till they convince me that they 'fit' and that they have at-least one super-power.

Of-course; they are all 'good' --- I am sure some even smarter than I am; but the question that is on my head is different.

How many of them can clear the litmus tests? --- I find myself thinking aloud.

The Litmus Tests

During the course of working with multiple teams which worked on some decently interesting products; we came out with a set of litmus tests.

Before we go ahead with the whole idea of litmus tests; it is hugely important; dear reader; that you know and understand one dirty little secret of recruiting genuine builders.

This is big.

So big that most managers go into denial when they are told this secret of recruitment.

Steve Yegge; explains this deep dark secret of recruiting genuine builders with true competence in his post on Smart-And-Getting-Things-Done. He explains:

The second prong, that of the ability to recognize true competence, has major ramifications when we conduct interviews. That's what Joel was writing about in Smart and Gets Things Done, you know: conducting technical interviews.

How do you hire someone who's smarter than you? How do you tell if someone's smarter than you?

This is a problem I've thought about, over nearly twenty years of interviewing, and it appears that the answer is: you can't. You just have to get lucky.

So you can go out there; 'formalize' your interview process; conduct five rounds of interviews; check all the past experiences, educational background and take all the IQ tests you want but if interviews are your only means of selection; chances are; that if you are not lucky; you can land up with a hardcore whiner.

Now that you know you cannot pick the most genuine of builders without getting lucky; the best approach; to take; dear reader; is to eliminate as many whiners and the assholes as possible and throw them out of the pool before you get yourself blind-folded and throw the dart.

The more whiners you have been able to weed out before you take your pick; the higher your chances of picking the genuine builders will be.

This is precisely where the litmus tests of recruitment come in.

If you really want to understand what Litmus Tests are take a look at some out there. A very famous example of a litmus test for programming logic is the famous Fizz-Buzz example illustrated at Imran explains:

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call "FizzBuzz Questions" named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can't. I've also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

While FizzBuzz questions act as a good litmus test for programming logic; multiple other litmus tests exist which can help you cover areas ranging from design; testing to general work interest and enthusiasm. Here are some examples of litmus test questions that you; dear reader; can use out of the box to access the overall technical competence, approach and attitude of the candidate.

Tell me any three technical questions that you can answer and then answer them.

Is the candidate lost; can he think of three questions he can answer confidently. Does he stick to simplicity or does he pick a complicated set of questions to impress you and then ends up blowing it. Based on the questions candidates pick; probe deeper and you know who not to hire.

Talk about three of your strengths and three of your weaknesses.

Most candidates when asked these questions describe their strengths rather articulately but come up with ridiculously stupid and artificial weaknesses; the I-cannot-lie weakness being the stupidest example. When you cannot talk about your weaknesses openly it just tells me that either you haven't done any soul-searching what so ever in your career; or you are a blame driven asshole who points a finger at others every time the sky starts falling.

Talk about one project where you were hugely successful and one where you failed miserably.

Any candidate who tells you that he hasn't ever failed falls in either one or all of these categories:

  1. He has never taken a chance and has always remained in the realms of mediocrity.
  2. He is a compulsive liar.
  3. He goes in denial mode every time he encounters a failure. Chances are that he loops in the infinite loop of failure all the time.

Failures in your professional life are just as important successes. After all if you haven't had seriously colossal fu@#k-ups and failures chances are; that you haven't learnt enough and that you're not going to be successful.   

The Thing About Litmus Tests.

"Ok Pops. I get the idea." --- you say.


Now you can go out there and create a few of your very own litmus tests. The one thing to remember about Litmus tests is that they are not supposed to help you pick the genuine builders for hiring. All they are supposed to do is weed the whiners out. Put simply; the fizz-buzz question; for example; will not tell you if a candidate is a good programmer; but it'll tell you if he is a bad one.

Go prepare your own set of litmus tests that are based on your selection criteria and weed out as many whiners as you can. Then take a chance and hope that you get lucky.

I wish you good luck.

What do you do to weed out whiners and pick genuine builders who; if left alone will automatically create remarkable work and play environments?

How many times have you been successful in picking genuine builders and how many times have you failed?

What litmus test questions do you use while interviewing candidates, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Friday, July 3, 2009 9:26:24 PM UTC by Rajiv Popat  #    Comments [0]
Posted on: Thursday, July 2, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 2.

Hiring - Where It All Begins And Ends.

Recruitment Managers at Multiplitaxion Inc, look at me like I am an alien talking a different language all together. I've interviewed a hundred people; rejected all of them and have proven beyond doubt that there is something wrong with my eyes and scanning abilities.

All hundred of the candidates interviewed cannot be idiots after all.

Or can they?

Sadly enough no one out of those hundred candidates seemed to fit the criteria of people I would love to work with or even closely match people I was already working with.

'If you take this approach we are never going to be able to hire anyone.' --- I am told.

A subtle nudge that is supposed to tell you that it's OK to lower your criteria and pick the best from what you are getting. We would then go out and make a big noise about hiring the best of the employees.

That is exactly what most organizations do.

Put simply; this is one phenomenon Joel Spolsky describes rather elegantly in his post on hiring the best. Joel explains:

Now, when you get those 200 resumes, and hire the best person from the top 200, does that mean you're hiring the top 0.5%?


No. You're not. Think about what happens to the other 199 that you didn't hire.

They go look for another job.

That means, in this horribly simplified universe, that the entire world could consist of 1,000,000 programmers, of whom the worst 199 keep applying for every job and never getting them, but the best 999,801 always get jobs as soon as they apply for one.

So every time a job is listed the 199 losers apply, as usual, and one guy from the pool of 999,801 applies, and he gets the job, of course, because he's the best, and now, in this contrived example, every employer thinks they're getting the top 0.5% when they're actually getting the top 99.9801%.

In the same article Joel also introduces you to the notion that genuine builders are not really going to be sending out their resumes and applying for a job:

In fact, one thing I have noticed is that the people who I consider to be good software developers barely ever apply for jobs at all. I know lots of great people who took a summer internship on a whim and then got permanent offers. They only ever applied for one or two jobs in their lives.

On the other hand there are people out there who appear to be applying to every job on I'm not kidding. They spam their resume to hundreds or thousands of employers.

A lot of times I can see this because there are actually hundreds of "job" aliases in the "To:" line of their email. (Some evil part of me wants to "reply-to-all" the rejection note I send them, but I usually overcome the urge).

What Joel is doing is pushing the idea of reaching out to really smart college interns and hiring them before they get a job opportunity anywhere else.

He is also pushing the idea that in case of genuine builder it is often your organization that might have to approach and quite literally beg them to join. Waiting for the resumes to show up in your inbox is not going to work. Neither is looking out for resumes on job sites going to be a very effective technique.

In multiple organizations around the world I've seen selection criteria come down merely by the virtue of the fact that a hundred candidates have been interviewed and none have been selected. When you cross the magical figure of hundred or more; suddenly; panic strikes. This is when organizations go out there and hire the 'best' out of the pool of idiots they interview.

Having your selection criteria crystal clear and not compromising on it is the first step to hiring a team of seriously kick-ass builders. Of-course Recruitment managers; and teams responsible for hiring candidates; are supposed to pressure you to go out and hire from the bucket of mediocre idiots that are being thrown your way. Providing these gentle nudges is a part of their job.

Most recruitment professionals and placement consultants are evaluated by the number of people that they place. It is therefore no surprise that the expert in them want you to lower your criteria. Most organizations out there actually have a whiner recruitment plan so they want you to lower your criteria as well.

Your job on the other hand is simple --- don't panic.

Hiring people who you are not fully satisfied with is your sure shot step to creating an environment that needs to be managed and anything that needs to be managed actively does not sustain itself in the long run.

Whatever it is that you do; don't panic; don't compromise.

I see multiple versions of the whole 'talented guys are limited'; 'we cannot be hiring all rock-stars'; 'we will never be able to hire at this rate'; arguments being thrown by multiple individuals and organization. Any organization that knows anything about software development turns a deaf ear to these arguments. Steve Jobs; for example; explains the process of hiring and how painful it can be rather articulately in his interview at business week:

Yes, it is. We've interviewed people where nine out of ten employees thought the candidate was terrific, one employee really had a problem with the candidate, and therefore we didn't hire him. The process is very hard, very time-consuming, and can lead to real problems if not managed right. But it's a very good way, all in all.

Most Recruitment professionals will frown when they read this. Steve Jobs; on the other hand; also has a reaction to the argument of managers and organizations not having the time to recruit people at this speed; which he describes rather articulately in the same interview with business week. He explains:

I disagree totally. I think it's the most important job. Assume you're by yourself in a startup and you want a partner. You'd take a lot of time finding the partner, right? He would be half of your company.

Why should you take any less time finding a third of your company or a fourth of your company or a fifth of your company? When you're in a startup, the first ten people will determine whether the company succeeds or not. Each is 10 percent of the company.

So why wouldn't you take as much time as necessary to find all the A players? If three were not so great, why would you want a company where 30 percent of your people are not so great? A small company depends on great people much more than a big company does.

Remember; of all the things that you are going to do to build a genuinely awesome work and play environment where builders thrive and flourish; recruitment is the most important.

It is so important I could quite literally do a complete book on it; but the whole point here is rather simple --- recognize the importance of hiring the right people; have a clear criteria for the team and whatever it is that you do; do *not* compromise on the people you hire.

If you can do that; most of the great work and build environment is pretty much going to happen automatically. If you don't you have lost the battle before it even begins.

Taking the simple approach of We-have-to-live-with-what-we-get does not cut it. All this approach does is create an army of whiners; faster than you know it.

What is your interview to ratio of candidates selected to the number of candidates rejected?

How many times have you been pressured or gently nudged; to settle for less when it comes to selecting candidates for your team?

How many times have you given in to the pressure, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Thursday, July 2, 2009 10:02:18 PM UTC by Rajiv Popat  #    Comments [1]
Posted on: Tuesday, June 30, 2009 by Rajiv Popat

Building Remarkable Work And Play Environments - Part 1.

One of the thing that fascinates me is an environment and the vibe that I get from an organization when I walk into it.

As a consultant I've worked at countless client offices around the world. During this period of my life as a consultant I have seen a few environments that are capable of housing genuine builders and giving them room to maneuver; thrive and flourish. I've also seen a few environments that would make a genuine builder uncomfortable to an extent that he runs and never comes back.

The fact of life however; is that most environments fall somewhere in the middle. Smack in the realms of mediocrity which is good enough to get your work-at-hand done but not cross the chasm of innovation and build something that is genuinely remarkable.

This is why most software companies; irrespective of where they are located hardly do anything which makes big or small dents in the universe.

When I talk about your organizational 'environment' I'm not just talking about how your office looks; how big it is; or what your decor looks like.

Environment is more a state-of-mind; a reflection of your organization's personality.

From the very first vibe that you get when you walk into an organization to the feeling that you develop for the organization after working there for a couple of months --- that's what I like to call your work environment.

That is exactly what I've been interested in observing for quite some time.

Observe a wide range of organizations long enough and you can't help but ask a few simple questions:

  1. Why do some environments have the best of the builders; while others struggle to find even decently good candidates?
  2. Why are some organizations able to make really big dents in the universe; while others are unable to make even a tiny dents on their own backyards?
  3. Why do some organizations need teams of just three builders to change the world; while others find it hard to survive even with armies of consultants?
  4. Why do some organizations have builders sticking around year after year; while others struggle to keep their revolving doors from stopping for sometime?
  5. Why do some organizations have style; finance and brand loyalty; while others are just cheap body shops selling cheap brainless bodies?

These are questions; most managers and organizations; have been trying to answer for a very long time. The answers I believe lie in observing some of these teams and organizations very-very closely. 

Everything you will be reading in this section of this book comes from an exercise which involves taking three simple steps:

  1. Studying companies that are successful and observing individuals who have been able to made a big dent in the universe.
  2. Observing the organizations that are getting it wrong and trying to figure out why they are going wrong.
  3. Trying to figure out what is so hugely different between these two organizations or should we just say --- trying to figure out what's wrong in the underlying approach of the two organizations.

Google is often regarded as the holy grail of software development world. It is one company that has undoubtedly changed the face of the world and how we interact with the internet. 

Stories, articles and videos of the great work environment at Google are littered all over the bathroom walls of the internet.

CEO's; CTOs and Vice Presidents look at these stories, videos or pictures littered all over the place and cringe at the mere thought of spending millions in trying to build environments which can compete with Google environments.

The safe line of defense you hear these folks speaking is --- 'We're not Google'.

Now that is one line I've heard from friends, acquaintances and sometimes even professionals in offices of the clients I have worked with.

If you've said this before; I've got to be completely honest with you dear reader and give you a little secret you can use.


You do not have to be Google.

In fact; you should strive really hard to see to it that you do not become Google.

The Google element of charm and surprise is  taken. It's old. Trying to mimic Google is going to get you nowhere. 

As a matter of fact; trying to mimic any work environment is stupidity at its height.

When I say that; I also mean that trying to mimic the typical-factory-floor model of how people do stuff in 'big companies' and 'body shops' is also something you might also have to consider stopping immediately.

What you need to do is think and come up with ideas that will work in your organization.

Creating work environments for builders is easy. Whether you are a CEO; a Vice President; a Manager; a Programmer or just another employee; I am here to tell you; dear reader; that you can make a difference in the overall thought process of the organization and the overall work environment by making small changes at your very own personal end.

What I intend to do in this section of this book; dear reader; is show you how easy it is to create an environment where builders can not just thrive; flourish and grow but also feel proud enough to spread the word and attract other genuine builders to join in.

It goes without saying that as we move along I will be expressing my ideas and proving my points through the act of story-telling.

The intention here is not to try and preach the list of 'N' things they can do to create awesome work environments.

I wish it was that easy as that and I wish I had the list of those 'N' things but I am really sorry; I don't.

When it comes to creating the best of environments I personally believe that there is no one right answer. My intention here is to give you an insight into the builders mind and what makes a builder happy; motivated and productive not just to stick around but to rope in other builders he knows.

At the very grass-roots level; creating an environment of this sort requires three fundamental things:

  1. Time.
  2. Thinking like a true builder and having genuine empathy for your employees. 
  3. Common sense.

That's easy Pops --- you say. Well personally I believe that getting your organization to genuinely adapt to these three simple bullet-points is going to be the hardest thing you might every do in your current job.

During the course of this book we'll look at some obvious common sense driven aspects most organizations; managers and HR professionals seem to miss out on completely. We will also talk about a few things everyone sees but no-one cares about; even when some of these things are hugely important.

Before we start with these stories in the posts that follow; lets end this one with three simple questions for you to think about.

Do you look forward to going to office on a Monday morning?

How would you rate your work environment on a scale of one-to-ten?

Is your organization even interested in collecting your rating and then acting on it, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Tuesday, June 30, 2009 10:29:47 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Friday, June 26, 2009 by Rajiv Popat

SQLDBCrypt - Open Source Database Encryption For SQL Server.

Free And Open Source Field Level Database Encryption For SQL Server 2005 and Later.

At work we design and build financial applications. When you are in the business of building financial or banking applications your database will contain sensitive information including account numbers and accounting information that you want to protect obsessively.

Multiple layers of security becomes important in cases like these.

The first layer of-course is the SQL server built-in permissions and security.

At a second level you want to lock out everyone's access on the production servers so that they cannot grab the data-files or access the database directly.

The third  layer is encrypting certain pieces of information at the field level and encrypting sensitive fields so data inside the database cannot be read by anyone even if he has direct access to the database --- this includes even the database administrators and the support staff who will be managing database servers.

Making your life simple with adding this third layer of security is exactly what SQLDBCrypt does.

SQLDBCrypt is an in-house SQL Server 2005 based encryption engine that we developed as a side hobby project.

Put simply; at a basic level SQLDBCrypt does exactly what commercial products like XPCrypt do; except that SQLDBCrypt is free and open source.

We have been using this product to encrypt and decrypt sensitive data that goes in an out of our applications for over a year and are very happy with the results.

The story behind SQLDBCrypt was somewhat on the lines of 'an idea conceived and implemented by a single builder'.

Abhijit Ghosh; who gives you a very sinister smile when you ask him if he has a blog or a web presence; is a very capable DBA and a programmer rolled into one; who works on my team at work.

Sometime a couple of years ago he conceived the idea and decided that he wanted to take this project up as his official assignment.

Early on in the project; we decided to give him time to do get a prototype done; get him everything he needs, wish him luck and get out of his way.

A few weeks later we were playing with a working prototype using which; we were able to get it adapted inside of eFORCE as a formal product with a formal testing and development team that would move the product forward and use it in some of flagship products.

Within a few more weeks we had a working version which was fully tested and which was being used in some of our financial applications.

We have been using SQLDBCrypt internally since then.

When you work in flat organizations where even the top most management understands software development; decisions of this sort are often done without any meetings or any committees. After more than one year of usage in production environment we at eFORCE recently discussed the idea of taking SQLDBCrypt to open source and were able to get a green signal literally in less than three days. No long-winded discussions; no meetings and no committees.

We moved the code base on CodePlex for you to try it out and give us your feedback; dear reader.

If SQLDBCrypt interests you; we suggest you start by visiting the Product Home Page on CodePlex

We're licensing this code under the New BDS license which allows you to use this product even in commercial projects without any of the typical restrictions that you get in commercial products and other open source licenses.

The source code for the project is available live; so if you really want to review the security aspects of the code and send in your suggestions; you can totally do that.

The project started as a fun project and slowly matured into something which was reliable and something we could use in our own product stack. We clearly did not have any intentions of competing with commercial database encryption companies out there but when we were done we did some basic benchmarking of the product with other commercial products like XPCrypt and in cases of huge data sets found SQLDBCrypt to be around ten times faster.

While we are talking about comparisons it might also make sense to talk about limitations of SQLDBCrypt while comparing it with other products out there.

While most commercial products like XPCrypt support multiple encryption algorithms we are starting with support for MD5 for hashing and RC4 (128 bit) for encryption.

We will be releasing support for other algorithms moving forward and are expecting community contributions for adding support for additional algorithms moving forward.

To add to that; while commercial versions of products like XPCrypt work on older versions of SQL Server; SQLDBCrypt uses SQL CLR and requires SQL Server 2005 or later.

Currently we are keeping the team size really small but going forward we will be adding team members as and when required.

We will be doing a formal series of benchmarking tests, posts and examples of how you can use the product going forward; but if you have a need for this product we would encourage you to try it out; beat it up; bench-mark it yourself and let us know your comments and feedback.

We are calling the current version a beta release for the next few days till we reach decent packaging and add all the bells and whistles of a formal product to it. Having said that; we really want you to download this version; play around with it. See if it meets you needs; if it does go ahead and use it in your projects. Feel free to let us know your thoughts, ideas or any bugs you encounter while playing around with this product at the Project Task List on CodePlex.

If you would like to start added discussions around the product or any of it's features feel free to use the product's discussion board at CodePlex.

If you like the product; and the fact that we have decided to release it as a free and open source component; go spread the word. Tell your friends; blog and tweet about it.

If you do not like the product; please do tell us why and where you think we can improve the product.

We love the idea of supporting whatever it is that we write and would love to take in suggestions on changes or features which can improve the product.

As much as I would like to recommend this product highly to everyone; the fact of life is that it addresses a very specific problem and if you do not have the need; the product in all it's glory is not going to make any sense to you.

If you are building a Library tracking system; this product is clearly something you do not want to waste your time investigating.

On the other hand is you are building a system which is going to store information worth protecting obsessively; examples being; banking applications; finance applications; or anything that stores sensitive information like account numbers; credit card information etc; --- go give this application a try before you go and buy some of the commercial products out there.

Do let us know your comparative analysis and what you think.

More announcements and open source goodness coming soon.

Stay tuned.

posted on Friday, June 26, 2009 9:50:21 PM UTC by Rajiv Popat  #    Comments [1]
Posted on: Thursday, June 25, 2009 by Rajiv Popat

Observing And Understanding Genuine Builders - Part 13

Selfish, Lazy And Not Big On Being Ethical.

I'm the Frankenstein's monster.

I'm talking about downloading office space trailers from you-tube using the office bandwidth.

A 'Few Good Men' working for the best interest of the organization stare at me like I've just dropped a stinking dead carcass in a meeting room.

"But that is not very ethical" --- says someone.

This is it.

The moment when the room fades into the grayness and you can clearly see the white differently from the black.

This is when I am hit by an instant flash of lighting.

I know exactly what I want from the candidates I interview to join my team. Besides, technical competence and a truck load of qualities I already talked about in this book; I am going to pick my builders based on three simple additional qualities:

  1. Laziness.
  2. Selfishness.
  3. Does not bitch about ethics.

Of-course; I know you're knitting your brows already. I know I owe an explanation to what I just said. So; let's get on with the explanations.

Get Me Someone Who Is Lazy.

I'm staring in awe at Fred as he demonstrates his sort-able grid view. He spent months building it. He is flexing his engineering mussels. He is one proud hard working builder.

I'm sorry.

I would prefer someone lazier.

Someone who would just go out there and... buy a sort-able grid.


I have no problems with you building stuff; but going out there and building the thousandth sort-able grid isn't my idea of innovation --- unless of course you are in the business of building grid views.

If you're not you might consider not flexing your engineering mussels of heroism and you might consider buying that freaking grid-view out there.

Having said that; genuine builders love the idea of building stuff. At work; when we landed up with an application needing fifty reports we decided to get lazy and build an ad-hoc reporting system which would allow the end-users to do their own reporting.

Genuine innovation doesn't happen by building the same grid view, reports or CRUD application a thousand times over.

It happens by indulging in the act smart laziness.

Get Me Someone Who is Selfish.

At work my every single day revolves around my selfish interest which over a period of time has co-incidentally intertwined really well with my organizational interest.

When that happens and interests intertwine builders stick around. 

During my days as a young and budding engineer; I was conducting three trainings a week on topics ranging from .NET to usability. Even today I try my best to conduct regular trainings at work.

Anyone who tells you that he is conducting these trainings or knowledge sharing sessions for the best interest of the organization is giving you a truck load of horse shit in it's rawest form.

I conduct trainings because:

  1. I get to learn new things which I am going to train others on.
  2. I get better at communication.
  3. I get to flex my engineer mussel and show-off how smart I am.

Training; is just an example. I pick it because conducting a knowledge sharing session seems like the most selfless of acts. I am here, dear reader, to tell you that it isn't.

Nothing is. 

Builders don't work under the false pretence of doing a favor to the organization or working for the best interest of the organization.

Anyone who does that is a hardcore whiner.

Make no mistakes.

Every single genuine builder out there who is worth his salt; is going to work for his very own selfish interest.

Organizations that align themselves to the best interests or their genuine-and-totally-selfish-builders; win.

The famous twenty percent time at Google is just one over hyped example of this happing in the real life.

There are tons of others out there.

Keep your eyes open and you can come up with your very own remarkable ways of taking the most selfish interest of your builders and aligning them with the interest of your organization.

Try to make your builders work for the best interest of your organization and you will end up doing is indulge in the act of sending your organization down the boring road of mediocrity.

Someone Who Does Not Bitch About Ethics.

Genuine builders tend to love what they do.

Besides their life long passion for their work and a consistent commitment; most builders that I have worked with are amazing fun loving people who do crazy fun loving things.

Walk into a software 'thinking' development shop and it isn't unusual to see a few programmers with their head buried deep in their monitor; their ears stuffed with head-phone.

Quite a few of the builders I have worked with have varied kinds of music they like to code by.

Others have a hilarious collection of funny videos.

Some of into Sudoku.

Others are into X-Box games.

In fact; even when it comes to software development and work; most seriously kick-ass developers live outside their cubical.

If you're going to be constantly bitching about how much of your time and bandwidth usage is for work and how much of it is for personal reasons like fun and growth; software development isn't for you.

What you need to do is get a job at the car-factory-work-shop or an Indian-call-center.

Now stop hitting that stupid ALT+TAB window and switching from you-tube to the code window every time your manager passes by.

Try not to obsess about what is ethical and what isn't. Instead; consider having a blast and shipping some seriously kick-ass innovation.


At the end of the day it's like this --- those who bitch the most about ethics; have very little of it.

Now; go hire a few selfish programmers who do not constantly bitch about the best interest of the organization or ethical code of conduct. All they focus on is just their very own selfish interest of growth; building stuff and having a good time doing that.

I wish you good luck.

Oh; and one more thing --- if you are reading this from your office don't forget to watch the office space trailer on you-tube using your company bandwidth --- parts of the movie are what I call utterly hilarious.

How many times do you hear big words like, right, wrong, discipline, ethical and unethical in your workplace?

How many times does your organization expect you to work for the best interest of the organization and not give a shit about your own interests?

Does your organization work on factory rules and no trust; or is it an environment where builders are genuinely empowered, dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Thursday, June 25, 2009 9:39:21 PM UTC by Rajiv Popat  #    Comments [2]
Posted on: Tuesday, June 23, 2009 by Rajiv Popat

Observing And Understanding Genuine Builders - Part 12

I'm Just Working For The Best Interest Of The Organization.

"All I am trying to do is work for the best interest of the organization."

The next time you hear those words --- run.

As fast as you can.

And whatever it is that you do --- Don't look back.

If you just heard those words from someone you know; with all due respect to this acquaintance of yours; chances are high that he is either of these three:

  1. A certified prick who utterly and thoroughly enjoys being an asshole. 
  2. A Hardcore whiner who is also a self proclaimed well wisher of the organization.
  3. A cheap Indian programmer who in all probabilities is working off a cheap Indian outsourcing shop.

"But Pops; you are hyping this up" --- you say.

No I'm not.

I know what I am talking about.

Trust me.

I've heard these words countless number of times and every single time I've heard them; the bearer of these words have fallen in one of these three categories.

Still knitting your brows; are you?

It's time you take you back in the depths of time and dig from ages that have rolled behind a few stories from the war fronts of software development; that shall illustrate my point dear reader.

Flashback time!

I Removed The Reporting Server

Multiplitaxion Inc, is a new client of ours; their product is struggling to cope up with the traffic during afternoons. We have been called in as a consulting organization to figure out how we can speed up the performance of the application.

The programmers are introducing level-2 caching into the system; the DBA is tweaking the stored procedures.

We've spent days analyzing at our end. Our findings are simple --- the afternoon loads are heavy; the system could do with another reporting server having a specialized reporting database.

Here is the creepy part however --- buried deep down in the physical architecture diagram of the system created a couple of years ago; is a box called 'reporting server' which stands proud and tall. 

Confused; we decide to interview the entire team including the Database Administrator who is working on tweaking the stored procedures.

'Oh the reporting server --- that was costing us a lot of money. We got rid of it. We can get this to work by tweaking the stored procedures'. --- it is the database administrator speaking.


Sounds of crickets chirping.

I turn around to the CTO; suspecting the highest in the pecking order of usually being the asshole in these cases; throw a simple question --- 'Did you ask them to do this?'

The answer is a cold --- 'No'.

More silence.

More crickets chirping.

"What? I still feel we can run without spending money on the reporting server. All we need to do is tweak the stored procedures" --- we are hearing the database administrator speak; but a very few people in the room understand the language he is speaking.

You have to give the guy some credit.

After all; he was indeed working for the best interest of the organization.

We're just trying to make sure we utilize the company bandwidth for official purposes only

I can't seem to figure out how I got here.

I am staring at a snickering system administrator who finds the idea of downloading videos from you-tube using office bandwidth as grossly unethical and amusing at the same time.

There is one little problem however; the video is a hilariously funny and inspirational; I want to share with my team.

"We're just trying to make sure we utilize the company bandwidth for official purposes" --- I am told.

I hail to the self proclaimed well wishers of the organization.

Then I buckle up to take this further with people in the organization who have the enough power and common sense to understand.

We can reward him by giving him more challenges.

Jack is working hard. Seriously hard.

We've been struggling to get this release out and Jack has been up practically all weekend.

The project has just shipped; the sky is blue and the birds are singing.

His project manager gives him a complementary leave to rest and heal from the bruises of a difficult war. 

In the copy-list of the email are a few others higher up in the pecking order.

Someone responds --- this gentleman who is responding after removing Jack's email from the trail; thinks that we cannot be giving off complementary holidays as easily as this. He proposes:

  1. Cancel Jacks complementary holiday.
  2. Offer him more 'grow opportunity' by giving him more challenges; spelt ---- "more work".
  3. We all collectively work for the best interest of the organization even when rewarding team-members.

I'm not directly connected or concerned.

I decide to shut the fu@#k up.

The Late Marker And The Break Time Calculator

Fred is interviewing with us. Here are his achievements besides work:

  1. Suggested development of a 'late marker' that marks employees late if they get in after nine in the morning. Three late markers results in a leave getting deducted.
  2. Suggested development of a break time calculator that is going to track the number of minutes individuals spend during their break time.
  3. Developed the perfect Frankenstein style - 'employee cloning system' and cloned a couple of hundred micro management zombies.

Well actually, he didn't mention the third one; but while he was at it; working for the best interest of the organization; he might as well have designed a Frankenstein Employee Cloning system used to clone a few micro-management-zombies like himself.

Self Proclaimed Moral Police

I could go on with the stories for ever. In fact, given my observations I could probably write a dedicate hilarious book on this but it would mostly end up having a Daily-WTF flavor to it. 

For the time being however; let's not even go there.

Lets focus on the point here.

Every organization that I've visited, worked for, worked with, built a project for or observed has a few whiners who like to think of themselves as the 'well wishers of the organization'. People who have a 'job' of defending the organization from the scum of other employees.

I like to call them the 'self proclaimed moral police'.

They individuals; will try to protect every single square inch of the organization they can; starting from the internet bandwidth; the disk space on individual hard disk of developers; to printer paper by monitoring the number of printouts each developer is firing on a daily basis.

After observing countless number of these guys; screwing organizational morale; in my career; if there was one thing I learnt; it was how to spot these whiners in an interview; keep them out of your team and keep then out of the organization.

Spotting them is easy.

All you have to do is keep your ears open and look out for the golden words --- "for the best interest of the organization".

And when you hear those words, run.

As fast as you can.

Whatever you do --- Don't look back.

How many Daily-WTF-type examples under the name of the best-interest-of-the-organization have you witnessed?

How many whining self proclaimed moral police have you had a pleasure of working with?

How many of these decisions taken for the best-interest-of-the-organization ultimately ended up fu@#king up the organizational morale and eventually nudging it in the realms of mediocrity where cheap Indian body shops haggling over per-hour-billing-rates reside; dear reader?


Note: This article is a part of a Work In Progress Book. To Read connected articles read the Builders At Work category of this blog.

posted on Tuesday, June 23, 2009 8:59:22 PM UTC by Rajiv Popat  #    Comments [2]