In one of my earlier posts I claimed that project management had a lot to do with understanding the human mind. In the same post I also went ahead and admitted that I'm no expert at it. Having admitted that, the amount of time and effort I have been dedicating and still dedicate to understanding the human mind and people issues is as much as the time and effort I dedicate to understanding code.

As a matter of fact, the time I spend to understand human beings in teams is sometimes even more than the time I spend trying to read and understand code. Studying programmers and how they function in a team fascinate me; as much as programming does. After all, I love everything about software development and team dynamics form a huge part of it.

I've seen countless college interns, fresher's and even regular employees being recruited by companies based on their 'analytical skills', 'mathematical skills', 'academic qualifications', 'educational background' and 'grades'.

I've also seen a huge number of those decisions turn out to be complete disasters. I've seen a few top notch graduates from top grade colleges who have toped three rounds of technical interview turn out to be complete pricks and in-compatible when it comes to working in a team. I've also seen programmers with humble starts out perform, get the team together and drive projects through the doors of success.  

Some of these experiences have made me to think that maybe, just maybe, organizations that evaluate candidates simply by using these black-and-white-approaches of judging them simply based on their 'academic background', analytical skills' or even 'technical skills', might be missing out big time on opportunities of recruiting a completely different breed of employees with qualities which are just as, and sometimes even more important for successful implementations, rather than just having 'technically-kick-ass programmers' on the projects.

'Catalysts' form a part of these different breed of employees. DeMarco and Lister, in their book, Peopleware: Productive Projects and Teams (Second Edition), describes Catalysts and their contribution towards making a project successful:

I was teaching an in-house design course some years ago, when one of the upper managers buttonholed me  to request that I assess some of the people  in  the course (his project staff).  He was particularly curious about one woman. It was obvious he had his doubts about her: "I don't quite see what she adds to a project she's not a great developer or tester or much of anything." With a little investigation,  I turned up this intriguing fact: During her twelve years at the company,  the woman in question had never worked on a project that had been anything other than a huge success.  It wasn't obvious what she was adding, but projects always succeeded when she was around.  After watching her in class for a week and talking to some of her co-workers,  I came to the conclusion that she was a superb catalyst. Teams naturally jelled better when she was there.  She helped people communicate with each other and get along. Projects were more fun when she was part of them. When I tried to explain this idea to the manager, I struck out.  He just didn't recognize the role of catalyst as essential to a project.

I've worked with a couple of really awesome catalysts myself in my professional career. After having realized the importance of having catalysts in each team, I've also learnt that there is no one-step-formula for finding and hiring this breed.

These are candidates who will show up in your interview, will perform very averagely in them at the same time send you a very good vibe by connecting to you, their enthusiasm, passion for learning and connecting to other individuals resonating very strongly, leaving you completely confused on whether you should hire them for their potential and attitude or let them go because of their average scores in the technical rounds.

Just like hiring any awesome individual, in order to hire a good catalyst, you have to go with the facts, your experience, gut-feeling and then finally get lucky.

These are candidates who may not be able to solve those puzzles your organization wants you to ask them or answer all of those interview questions that good .NET developer aught to know but one of the biggest blunder managers and organizations can do is undermine their contributions.

I've personally witnessed countless occasions of failing projects starting to become successful over a period of time after a catalyst is introduced in the team. I've also seen successful projects starting to stumble when a catalyst leaves or is removed from those projects; and in all these cases the catalysts weren't contributing anything that can be described as majorly critical when it came to code or tasks in.

If you're building a team, leading a team, or working for a team, remember that the role of a catalyst in a team is as important as the role of the best programmer who is shipping the most complex and critical modules. Go ahead, look around you; or think of the people you work with. Is there a catalyst holding your team together? If yes, are you giving him due credit and appreciation for his contributions?

I've often been accused of being a pessimist. My pessimism comes back from the school days where I would announce, almost ceremoniously, how bad I had written my exam papers and how I might barely pass only to hit a 80+ or a A+ when the final results were announced.

My biggest strength at pessimism was that I was convincing at it. I could carry my pessimism tugged along with my depression using a very glum face; and I genuinely believed it too. If you were to put me on a lie detector and asked me how much I would score in that exam I probably would pass the lie detection test comfortably when I said I would just about scrap through or just about pass the exam. I would say that with a very serious and glum face.

Then I would go ahead and score a 80+ or an A+ when the results came out and you'd be wondering what just happened.

Acquaintances, teachers and most people who knew me considered pessimism to be one of my biggest weakness. They thought I was underestimating myself when all I was effectively doing with them was simple: I was lowering expectations.

When I entered the world of software development as a young an budding programmer and then a young and budding team lead, I realized that a little bit of optimism can make you your manager's pet and take you way ahead in your path to countless promotions and so-called-successful projects. I tried optimism and it sort of worked. I was successful but the success wasn't quite nearly as satisfying as I had expected.

I was frustrated; only to revert back to my true nature of a thick skinned pessimist who hopelessly under-promises, sells you the deal and then works his ass off to over deliver because he is freaking scared of failing in the end.

At work, I've been accused of being a pessimist by many. In past, I've been approached by Finance and Marketing people telling me that the organization had a long-pipeline of projects only to get my response that we should think about those projects only when the pipe line materializes and becomes real.

When it comes to recruitment and retention I'm continuously worried about my entire team quitting and on my feet to keep them happy; even when everything is perfectly fine. When it comes to projects I am constantly looking out for details which will cause the project to fail even when it's running comfortably well and three weeks ahead of time.

In an earlier post, I've already discussed my frustrations over being 90% done and have gone ahead and said that 90% done is as good as not done.

Pessimism is something that was always a deep rooted part of my character. However, I no longer consider it a weakens or something I need to work on changing.

If you're a programmer or connected to software development, Optimism and Wishful thinking are probably the two biggest vices you can be cursed with. Frederick P. Brooks in the classical legendary book, The Mythical Man-Month Essays on Software Engineering, explains:

All programmers are optimists. Perhaps this modern sorcery especially attracts  those who believe in happy endings and fairy god-mothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end  goal.  Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: "This time it will surely run," or "I just found the last bug." So the first false assumption that underlies the scheduling of systems programming is that all will go well, i.e.,  that each task will hike only as long as it  "ought" to take.

Steve McConnell in his book Rapid Application Development - Taming Wild Software Schedules believes that optimism taken at the next level of wishful thinking may be at the root of more software problems than all other causes combined:

I am amazed at how many problems in  software development boil down to wishful thinking. How many times have you heard statements like these from different people: "None of the team members really believed  that they could complete the project according to the schedule they were given, but they thought that maybe if everyone worked hard, and nothing went wrong, and they got a few lucky breaks, they just might be able to pull it off." "Our team  hasn't  done very much work to coordinate the  interfaces among the different parts of the product, but we've all been in good communication about  other  things, and the  interfaces are  relatively simple, so it'll probably take only a day or two to shake out the bugs." "We know that we went with  the low-ball contractor on the database subsystem, and it was hard to see how they were going to  complete the work with the staffing levels they specified in their proposal. They didn't have as much experience as  some of the other contractors,  but maybe they can make up in energy what they lack in experience. They'll probably deliver on time." "We don't need to show the final round of changes to the prototype to the customer. I'm sure we know what they want by now." "The team is saying that it will take an extraordinary effort to meet the deadline, and they missed their first milestone by a few days, but I think they can bring this one in on time." Wishful thinking isn't just optimism. It's closing your eyes and hoping something works when you have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blowups at the end of a project. It undermines meaningful planning and may be at the root of more software problems than all other causes combined.

Even after people with reputations as high as Steve and Frederick describe optimism and wishful thinking as one of the biggest problems of our industry I continue to be surprised by just how wishful people still exist in our industry.

I've seen companies continue on projects where the entire teams knew months in advance that the project would fail without doubt. I've seen teams continuing work on the project without uttering a word even when they were completely aware of the ultimate destiny of the project.

The decision to continue silently was clearly taken under the hope that something magical will happen whisking the project away on the path of heroic success.

I've worked at multiple client places. During my work at some of the clients, I've witnessed business deals being struck, companies being acquired and projects been extended all under the curse of wishful thinking when every single individual directly involved with the deal, the companies or the projects that I talk about, would have told you hands down that there was no way things could have "worked out".

Yet, the teams decided to continue; closing their eyes to the hardcore realities of failure. What they were doing was ignoring the possibilities of disaster outright blatantly.

Optimism and Wishful thinking are by far the Biggest Curse of Software Development and to a large extent and if you're working on a project where nothing seems to be going right and yet you find yourself continuing without uttering a word you're probably cursed too with these vices. Your only glimmer of hope is a touch of pessimism and every once in a while a splash of a cold water on your face to wake you up and show you the reality.

Remember, optimism and wishful thinking are the biggest curses in our industry. The next time you tell yourself that things will 'work out' ask yourself if you've genuinely evaluated the situation or are you just turning a blind eye to the inevitable?

Every now and then I’ll have one or two young and budding colleagues walk up to me and ask me what they can do to become what they refer to as 'project managers' or 'team leads leading their own teams'.

Project Management or for that matter any form of management is about understanding people’s mind and I’m not sure what makes people believe I have all the answers when clearly I am as clueless as anyone else when it comes to understanding the human mind. It's not as simple taking a few lines of code and looking at them really closely to analyze or debug them.   

I suspect it’s either my very-serious-sounding-designation or depending on the definition of success, a lot of successful projects and a few not so successful ones that I’ve been a part of that makes people think that I might have a clue.

To be honest however, here’s the secret: I don’t have a freaking clue about how the human mind works. Yes, I spend countless hours reader about this stuff and putting some of the principals and theories into practice but the reality of life is that I have very few answers. 

I’ve attempted to answer how young and budding engineers can start leading their own teams by not being a leader but the ‘what-can-I-do-to-become-a-project-manager’ remains largely unanswered.

There are actually two answers to the question depending on how you phrase the question. If the question is ‘what-can-I-do-to-become-a-project-manager’ the answer is simple:

Join an organization where you can butter your way up the corporate ladder and turn yourself into a budding politician.

On the other hand if the question is ‘what-can-I-do-to-become-a-good-project-manager’ that's a completely different ball-game.

My personal experience is that anyone who asks the ‘what-can-I-do-to-become-a-project-manager’ question hardly ever asks the ‘what-can-I-do-to-become-a-good-project-manager’ question.

Yes, they manage to drive their way through their company politics and become leads and project managers but they never quite get good at it. During my career I've also noticed one common problem with this crowd of desperately-want-to-become-project-managers who want to rise above code and climb the golden ladder of 'management' and leadership.

The problem: They start doing too much to make their project successful as soon as they becomes what can be technically called a ‘manager’.

Give any of these guys a small project to manage and before you know it, they will start:

1. Making Gantt Chats and Project Plans.
2. Writing up a communication plan.
3. Following Up on Programmers to find out what the status is.
4. Sending Status Reports depicting progress in percentages.
5. Having a huge number of meetings every day.
6. Sucking up on their bosses.
7. Writing a lot of documents and making others write a lot of documents.
8. Going out of their way to slow down their team and make their life miserable by decreasing the general 'happiness factor' within the team.
9. Writing And Maintaining To-Do Lists for not just themselves but everyone else in the team.
10. Doing a whole lot of additional crap to pamper their own egos and justify their own existence.

If there’s anything I’ve personally learnt by being a part of a few successful failures and a lot of other successful projects it is that if there’s any list that you possibly need as a manager, it is not a To-Do List.

What you need is in-fact, is something that can be described as a “Not To-Do List”.

There you go; If you are a budding young manager, I just gave you a little trade secret. Seriously. You need a big fat list of things which you will 'not' do as a manager; If you are serious about this becoming-a-good-project-manager thing, start writing one; right now.

Here’s how you write a Not To-Do-List:

1. You take A Piece of Paper and something that you can write with like a pen or a pencil.
   (Or your could just open up a new blank Text File using Notepad)
2. You write down every single thing that you promise yourself you will try your best to “not do” as a manager.
3. You maintain the list religiously and stick to it as you move forward.

The best way to add items to this list is to look back on your days as a Junior engineer and try and recollect as many things you can about your managers back then that you hated. Other than that you can also watch every single thing you screw-up and every single screw-up that happens around you very closely.

Dissect each of these failures in your head and analyze them. Take every failed project and endeavor in your organization and analyze those, just like people listen to the black box after a plane crash. A wise man I worked with once told me that every failure is different. It has a story and that there’s usually something new to be learnt from each one of them. If you keep your eyes open you’ll realize that all projects failing can be broadly classified into two categories:

1. Incompetency of team members – which is why I’ve always said that it’s kick ass programmers who build projects; not Gantt charts.
2. A prick in the project team – if you investigate further, most investigations will reveal that this prick is often whom we glamorously proclaim and refer to as the Leader or The Project Manager.

This brings us to the soul of this post.

It's actually been a rather wordy post; and we're barely starting to touch the point I'm trying to make. If you've read so far, I saute you. If you haven't; all I’ve done with all these words is propose two simple ideas:

1. If you’re a manager you need a “not to-do list” which you list out things which you should not do as a manager.
2. Not Being a Prick is something that should top the list.

Not being a prick is so important; Michael Lopp uses the idea as an awesome starting point for his book Managing Humans. The book begins by describing how a single prick can destroy not just a project but an entire organization:

Flash back to the middle of the dot-com implosion. We, the merry crew of the failing startup, are drinking... a lot. There are various bars around corporate headquarters, and each has a distinct purpose. There’s the dive bar that’s great for post-layoff parties. The booze is cheap, and if you’re looking to blow off some I’m-really-not-worthless steam, you can pick a fight with the toothless sailor slung over the bar or the guy who just laid you off. Down the street is the English pub. The beer is better, they have a selection of whiskey, and they have edible food. This is where we get philosophical about the current organizational seizure we’re experiencing in our three-year slide toward irrelevancy. We’re there now. We’re drinking heavily because the company has just been sold to a no-name public company who will quickly dismantle the one for which we’ve bled. Everyone knew we’d be here at some point, but no one expected to be the last one standing. And no one expected the CEO to show up. This isn’t the CEO that built the company. He’s been gone for over a year. This is the guy the board of directors brought in to sell the startup. Sure, he tried to turn us around, but remember, we’re in the middle of a financial nuclear winter here. Money is no longer free. Those who got a glimpse of the CEO’s resume before he arrived knew the gig was up. His last four jobs ended in the company being finely sliced into nothingness. It’s called “maximizing shareholder value.” And here we are. Hammered on tequila, the last four from engineering, two guys from tech support... and the CEO. Even though we’re dizzy with booze, we’re fundamentally uncomfortable with the presence of our CEO because we consider him to be an unfeeling prick. And that’s it. That’s the title of my management book. Don’t Be a Prick.

Steve Yegge in his post on (Not) Managing Software Developers describes the one simple quality that differentiates a great manager from one that sucks:

However, I'll offer you one almost magical tip that can help you smooth over nearly any mistake, a tip that can get you through just about any bad situation. I'll tell you the tip right now, with no fanfare or ado. This hint is the most important one I'll offer you today. It's the secret ingredient to Great Manager Sauce. Unfortunately, it's not easy to learn. You either already understand it, down in your bones, or you have years of head-scratching ahead of you. The tip is just one word: Empathy. If you have true empathy for your engineers, they can forgive almost anything. Which is good, because you will make mistakes. We all do.

Recently an individual who is also a colleague and a close friend approached me informing me that he wanted to be a Manager because he was sick of coding and he thought it was time to grow professionally and stop being what he referred to as just-another-developer. He was thinking of moving over to project management and was thinking of becoming what he referred to as a project manager. My instant spontaneous reaction, in jest of course, had been that he'll never become a project manager. Even though it was a joke, It sounded like a really mean thing to say after I had said it; I wasn't politely articulate in explaining what I meant. Steve's post on the other hand, does a pretty good job at describing exactly what I meant:

If you want to manage badly enough, then you will manage, badly enough. Hence, before you jump in, stop and think about why you want it. Are you tired of engineering, or were you perhaps never very good at it? If so, technical management isn't much of an escape, because your engineers will know, and they won't respect you. Do you want to manage because you want authority? If so, it's a trap: you'll still be on a leash held by the folks above you. Or maybe you just want to be a little higher in the pecking order, so you can peck downhill? If so, then you're what we call, colloquially speaking, a "pecker". Think hard about why you want to be a manager.

If you haven’t clicked on the link to Steve’s post, click on it and read it word by word. I don’t care how long it is, do yourself a favor and read it. I'll post a link again so that you don't have to hurt your eyeballs looking for it - here you go - go ahead, click the link and read it. It's a great read. Honest.

Yes, after have worked your ass off to get promoted papering your ego feels like a natural thing to do now. In fact, chances are, that you may have already started or will soon start taking your first steps on the path of Prickdom but here’s my advice: Turn back; now; before it’s too late and the Prickdom gets embedded in your personality.

Resisting the temptation and disassociating yourself from it is what sets a veteran project manager apart from a want-to-be-never-going-to-be manager.

Of course, if you’re a manager, chances are that you’re making mistakes all the time. You’re probably making more mistakes than you can possibly think.  Really stupid ones. Your only glimmer of hope is that your team forgives your stupid mistakes and moves forward with you. Being a prick that they hate, doesn’t really help them in getting over every stupid mistake you have made in the past and moving ahead; with you. 

Going Forward, I’ll be posting more items for the Manager’s Not-To-Do List but Not Being a Prick is so important that it undoubtedly tops the list. In all probabilities it is also the most violated rule of project management.

Let's do a little exercise, shall we? List down all your bosses on a whiteboard or a piece of paper. Now stand back and take a long hard look and tell me; how many of them have acted like a prick during one or more occasions with you where if you had the power to fire them, the thought would have at-least cross your mind. Quite a few of them; right? Life sucks, doesn't it? But wait; there's hope.

Now look back at the names and realize how many of them have rarely done it and how many of them do it all the time.

The really good ones are the ones who realize they are being pricks, stop it, turn around and apologize. Very few, right? And chances are these are the ones you really respect. The kind you can hardly hear bad things about in a discussion with your co-workers and colleagues. For everyone else, you'll probably join in and take a kick out of the discussion.

The honest reality of life is that you'll find more managers with Prickdom infused in their personalities than you'll find managers who very rarely act like pricks. It goes without saying of-course that it would be really hard to find managers who never act like a prick.

That’s it my young-budding-baby-project-managers; that’s all I’ve got for you today. It’s been a rather wordy post but all I’m saying is that if you’re Managing Projects and working with (not managing) people, you need:

A Manager’s Not-To-Do List where Item one reads: Don’t Be a Prick.

If you still don’t get it, you’ll never be a manager; at-least not a good one; and not till the time you get a couple of tight symbolic slap on your face that makes you realize what we're talking about here. If you don't get it even when that happens, take the hint and stick to being a Know-Nothing Technical Director, an Arrogant Programmer, an Egoistic Business Analyst, a Bitchy QA Lead or whatever-it-is-you-are-good-at-being and spare us having to deal with another Pompous Manager who is basically a Prick.

On the other hand if you learn this lesson (even if you do it the hard way, by taking a few punches), try your best not to be a prick, and have first Not-To-do item in your manager's Not-To-Do list, implanted deep down in your head, your team will teach you everything else you ever need to know as you proceed, fail, stumble and make some really stupid mistakes while you lead them collectively through a highly successful projects or a highly successful organization. They'll stand by you through the thick and thin; as long as they know for sure that you're an not arrogant prick.

Start a Not-To-Do-List where the first item reads; Don't be a Prick. If this is one lesson you can learn like your life as a manager depends on it You’ll do good Mr. Manager; I wish you good luck.

When a very capable engineer and a great colleague, approached me in a project party and told me that I was turning into a meeting-man, I stopped and took a long hard look at myself. Even though he meant it as a harmless joke, it was really important for me to stop all meetings I was organizing and do some serious soul searching; instantly. From recruitment to project issues we were having too many random problems back then and every one of those seemed to warrant the need for a meeting. 

Even though that does sound like a convenient excuse to be organizing and attending a lot of meetings, the fact remains that attending and conducting too many meetings can turn you into 'the meeting man' who chatters away as others catch their zzzzz's during a meeting.

The folks at 37Signals have an interesting take on Meetings and refer to them as things which are toxic to productivity:

Do you really need a meeting? Meetings usually arise when a concept isn't clear enough. Instead of resorting to a meeting, try to simplify the concept so you can discuss it quickly via email or IM or Campfire. The goal is to avoid meetings. Every minute you avoid spending in a meeting is a minute you can get real work done instead. There's nothing more toxic to productivity than a meeting. Here's a few reasons why: They break your work day into small, incoherent pieces that disrupt your natural workflow They're usually about words and abstract concepts, not real things (like a piece of code or some interface design) They usually convey an abysmally small amount of information per minute They often contain at least one moron that inevitably gets his turn to waste everyone's time with nonsense They drift off-subject easier than a Chicago cab in heavy snow They frequently have agendas so vague nobody is really sure what they are about They require thorough preparation that people rarely do anyway

Whether you're responsible for recruitment, retention, company strategy or just running multiple projects and products; arranging, conducting and being a part of a lot of meetings and calls seems natural. After all, we as humans beings are social animals. We like to connect to and interact with others. But then, as you start conducting and attending more and more meetings something creepy happens: You Get Addicted.

The idea of being a part of something grand by comfortably sitting in a chair and talking sounds much more appealing than working your ass off while trying to solve real problems. Meetings tend to give you an illusion of being in control and everything working as per plan when in reality nothing is getting done.

Try to push yourself and focus on getting things done instead of attending countless meetings where plans of saving the world or your projects are discussed. If you are getting bogged down by meetings or are leaning towards organizing too many of them, you can start by taking really simple steps:

1. Turn Meetings Into E-Mail Trails: If you're going to be discussing controversial topic like recruitment or company strategy don't get into a meeting. Start mail threads instead. Mail is asynchronous; it gives you time to think, formalize your thoughts and put then down in a coherent, written down stream of ideas. Mail threads prevent you from getting into arguments and un-necessary confrontation during meetings. Whenever possible, replace meetings with mail trails. Specially for topics which are controversial in nature.
2. When given a choice, lean towards one on one discussions: At an organization level it definitely makes sense to have lots of meetings and involve as many people as possible but from a productivity perspective, everyone's business is no-one's business. When picking people who are invited in a meeting less is better. What can be solved by quick face-to-face one-on-one discussion with an individual should not be turned into a meeting containing two participants. 
3. Pull The Plug: Irrespective of what the topic is, The Folks at 37 Signals have a rather innovative answer to the problem: 'Set a 30 minute timer. When it rings, meeting's over. Period'. I would go so far as suggesting that you have a running timer flashed on a screen so everyone is well aware of the fact that time is running out and when you do run out of the pre-decided duration, pull the plug and end the meeting.

Meetings are truly like heroin of Software Development World. The more you indulge in them, the more you get addicted; even when you clearly know that they are injurious to your professional health. Don't get addicted by meetings and if you already are, try to stop attending them, now. When you do, initial withdrawal symptoms are bound to appear and the fear of having to sit down on your desk, figuring out innovative ways of finding out the status, doing some real work in a concentrated fashion might sound daunting and harder than simply going out there and talking to people, but remember, sitting down and working with a focused thought process is the only way to get things done.

Get together for a quick five minute stand up discussion with your team if you must, but next time you attend a long formal meeting ask yourself if it's really necessary or are you, in the name of good communication, just indulging yourself in an addiction which does nothing other than make you feel good about yourself and give you an illusion of being a part of something important when in reality all you are doing is wasting everyone else's and your own precious time.

This post is about a complex set of programming topics.

If you read the first sentence and deep down, behind the locked doors of your mind, liked the fact that you were going to do read something 'really important' this post is about you. Notice however, that I didn't mention the word 'important' in the first sentence. I just said I was going to talk about a few complex programming topics.

Complexity is deceptive.

We, as human beings in general and programmers in particular, tend to associate the word complex to words like important, accurate or correct almost implicitly when in reality complexity has no direct connection with these words.

Steve McConnell in his book Estimation: Demystifying the Black Art describes this human trait with the example of this effort calculation formula:

He explains why the human brain inherently tends to fall for things which sound complex:

Our natural tendency is to believe that complex formulas like this (the one above) will always produce more accurate results than simple formulas like this: Effort = Number Of Requirements * Average Effort Per Requirement

If you're at work, look around. Chances are that you'll easily find a colleague or a team working on a project which is a confused mesh of a Gazillion technologies all of which are collectively doing nothing but boosting up the ego of the programmers who work in that team.

I’ve talked to countless programmers, have witnessed multiple such projects and tried to figure out why we as developers keep making the same freaking mistakes, including the one of confusing complexity with correctness or accuracy.

As programmers, the inherent feeling of being involved in something ‘complex’ seems to give us a sense of pride and an ability to distinguish ourselves from the rest of the world which we seem to look down upon as ‘stupidly simple’. This is also probably why most consultants out there use unnecessarily complex Jargons.

Somewhere deep down inside, we believe complexity is good and we associate words like correctness or even accuracy to complexity.

Liking complexity seems to be an inherent part of human nature; which is probably why we like relationships in our personal life and complex processes in our professional life instead of focusing on the simple things in life and even simpler facts of software development.

We love complex; but only till the time we have had enough and things begin to get out of hands. It’s then that we start making desperate attempts to simplify things.

Besides our inherent love for it, complexity has another rather interesting feature. It happens.

It is in fact, to a large extent, this feature, that describes why we inherently love complexity.

Building something complex is easy. Building something simple, well, that requires a lot of hard work and is a whole new ball game; and that, I believe, is why we humans, lean towards complexity when it comes software and life.

Humor me and I'll do my best to prove my point. I promise.

Jeff Atwood sights an example of a complex piece of User Interface built by a software programmer:

How do you think the UI came about? I wasn’t exactly there peeping over the programmers shoulder but here’s my best guess on something like this comes about:

1. Mr. Developer throws some controls on forms.
2. Mr. Developer realizes that the application needs some more features.
3. Mr. Developer throws some more controls on the forms.

It's easy. See? No Thought Process, No White boarding, No worries or thinking about usability. Simply put, something as complex as the user interface about 'just happens'.

Simplicity, on the other hand involves a lot of a lot hard work. Thinking, re-thinking and a lot of discipline.

The folks at Tortoise CVS and Tortoise SVN are a classic example of how much thought process goes into it before you can just right click a file and check-it-in.

During the Project of the month interview the folks at Tortoise CVS, Torsten and Francis describe their ongoing challenge of keeping it simple to use, through remarks like:

What are a couple of notable examples of how people are using your software? There are some CEOs who use it to manage word documents and spreadsheets, something I don't think CVS had much use for before. Why do you think your project has been so well received? Francis: Because people like right-clicking. (Seriously!). Torsten: Because users feel that they don't have to learn a new application - they just use their old trusty Explorer or Total Commander with a few extensions. What's on your project wish list? Torsten: Getting rid of even more preference settings What are you most proud of? Torsten: Each time I have resisted the temptation to add another preference setting, and instead made the code smarter. How do you coordinate the project? We have a pretty small core development team: Hartmut and myself (several other people also contribute, but not on a regular basis). I handle everything related to releases, as well as the documentation and web site stuff. Apart from those things, there is no strict division of responsibility - we both work on the new features we find cool, and we both handle bug reports etc. via the trackers and the mailing list.

Tortoise is a classic example of how you can take something complex like version control and simplify it. If you've used Tortoise to work with CVS or SVN, the hard work that has gone into simplicity clearly shows in the form on elegance of implementation; and WGetUI? Well, one look at that user interface and anyone with any fundamentals of how software development works can tell you that the WGetUI is a software that 'just happened'. It is an example of how you can take a simple problem like file-download and solve it without any thought on usability or user interface; letting the development 'happen' as things pretty much evolve by themselves.  

The next time you reach out and proudly announce to your friend, colleague, relatives, family or acquaintances that you’re working on a system that’s very complex, it’s time to do some soul searching. Maybe your so-called-highly-complex-system that you are working on is something that is 'just happening' without any effort on your part to keep it simple; and that, I’m not so sure, is something to feel particularly proud about.

When was the last time you read a FAQ?

No, Seriously. When was the last time you 'actually' read a FAQ?

When was the last time you found a FAQ useful?

Thought So.

Kevin Kelly refers to Most FAQ’s on the web out there as “NAQ" or as he prefers to call them, "Never Asked Questions”:

That's what most company FAQs really are. Easily answered questions that no one has ever asked. These fake FAQs are useless. They are a turnoff to potential customers looking for reasons to buy, and an insult to existing customers troubleshooting. I now judge companies while shopping on how competent their FAQs are.

I've hardly ever found a FAQ section of any web-site useful. FAQs, over their long history have turned from something that was supposed to provide genuine help, to something that no-one reads and a rather elegant wall or facade behind which most support folks hide.

The idea of having FAQs wasn't always such a bad idea. The whole idea of documenting FAQs in-fact started with an intent that was good:

 History has it that FAQ’s were written primarily because the same questions were being asked too many times:

On 15 September 1983, Jerry Schwarz announced on net.general that he was going to publish a list of "questions not to ask". On 1 November, he published the first Usenet FAQ under the title "Frequently Submitted Items".

They were, as their name suggest, supposed to be 'Frequently Asked'. They were supposed to help; back in the old days; when we didn't have this thing that we all love and call 'Google', FAQ's as a matter of fact, did help.

Today, I have multiple gripes with FAQ's.

The biggest of my gripes is that they are not written with a genuine intent of helping end users. Go to any web-site that has a FAQ section glance through them. Chances are, that you'll find the following whole set of issues with the the made up questions and their plastic answers. You'll notice that the question and answers are:

1. Written by Non Technical Staff who usually come from backgrounds like marketing or content writing.
2. Written by folks who are usually overly aware and cautious of the organization's image in front of it's customers or potential customers.
3. Written to spoon-feed the users with questions the organization wants them to ask, not the questions the customers want to ask the product developers.

What historically started as a means for the technical folks to avoid repetitive answers in the community and support DRY communication, has gradually turned into a wall preventing customers from reaching the technical staff in a desperate attempt to lower the cost of support; or a place where a bunch of desperate marketers try to convince the 'potential' customers that their product works.

With all due respect to the marketing and PR folks, FAQ is supposed to be a support tool, not a marketing tool. Neither is it supposed to be a wall behind which the support staff hides.

The folks at 37Signals have a slightly different take on the whole support thing:

Avoid building walls between your customers and the development/design team. Don't outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too. At 37signals, all of our support emails are answered personally by the people who actually build the product. Why? First off, it provides better support for customers. They're getting a response straight from the brain of someone who built the app. Also, it keeps us in touch with the people who use our products and the problems they're encountering. When they're frustrated, we're frustrated. We can say, "I feel your pain" and actually mean it.

Kevin explains in his post also why real providing answers to real FAQ’s which can solve real problems and genuinely help customers are very difficult to write:

Real FAQs will often be difficult to answer. An answer may mean admitting mistakes, or acknowledge a weakness, or explaining something very complicated. It's okay. Take all the room and time you want. People will read it.

Let's face it. If your Web-site has a FAQs section it's probably going to suck. It's that Simple.

Don't have a FAQ. Throw them out of the window. Delete that FAQ page from your web-site. Right now.

Instead: 

1. Have product blogs with comments turned on so that product team can directly answer and respond to the questions. Let the search engines index those and help customers who have similar problems in future.
2. Have forums. Get your technical team to answer questions there. Undermining the power of the community and trying to replace it with a ‘one-way-communication’ like a static FAQ list is stupidity.
3. Provide email addresses and support numbers clearly and liberally on your web-site. If your customers have a problem with your product, your product team needs to take the responsibility and answer them. After all supporting what you write and being their for your customers is as important as writing the product itself.

If the same questions keep popping up again and again (and if you must), then, by all means, use a FAQ. But remember what a FAQ is supposed to mean in the first place.

Does your web-site have a FAQ section?

Is it written by your technical team or your Vice President of marketing?

Maybe it's time to give your FAQs a good hard reality check.

If they are not genuinely helping your customers consider throwing those stupid (In)Frequently Asked Questions out of the window.

I recently wrote a post on YAGNI and asking "Why" Before adding features which led to quite a bit of criticism and questions through a couple of comments, email and personal one-on-one discussions.

If you drop me a comment on this blog, usually I’ll respond to it as a comment because I feel it helps in maintaining continuity of on-going discussion. But then, the YAGNI post received a comment that was different. By the Time I had completed writing the reply to the comment I had already crossed a couple of pages and it sounded like it deserved a new post.

Rohit Jain responded to my post with a rather opinionated but interesting comment. By The time I had read the comment I was busting with a temptation of a six year old who knows the answer that was just asked by the teacher.

Just so that you don’t have to swap back and forth I post Rohit's comment here:

While the comment is fairly constructive in criticisms and deserves a reply I feel Rohit was a little mixed up with contradicting thoughts and ideas. This post is my humble attempt to put these conflicting and confusing thoughts and ideas in right perspective. Let's take each part of the comment, dissect it and try to answer it in the sprit of sharing ideas and learning something new. 

> We all do because it unarguably makes processes successful

The comment starts by seeming to suggest that YAGNI as this thing that makes a 'process successful' almost seeming to suggest that the guys who talk about YAGNI are guys who are so-anti-innovation that they are completely so-not-cool.

The way I see it, answering the 'why' has nothing to do with making the 'processes successful'. To me, 'why' is the the fundamental question that needs to be answered before you do anything. Of course, the answer to the 'why' can very well be 'because it’s fun' or 'because I like it' and that's perfect; but if you can’t answer the 'why', you are probably just wasting your time.

Early on in my career I started asking questions like: Why do we need to wear a tie to office? As I grew up as a developer the 'why' related questions became more and more profound and at the same time much more subtle. I asked why most organizations out there can’t trust their employee, why people seek refuge in documentation, why people need to spend fixed amounts of time in office and even why managers can't or shouldn't write code. If you read this blog regularly you will realize that this blog asks a lot of 'whys'.

My Post on Johnny Knapsack’s story is interesting in this context. Johnny Knapsack kept running with a Knapsack on his back without asking 'why' he needed the knapsack till he lost the most important race of his life. You can read the post here and the original story here.

The post and how I use the story is fascinating in this context because the post uses the story as an example of how you should move away from a rigid formal process by asking more 'whys'.

Clearly  asking 'why' has nothing to do with following the process or being un-cool.  

> Ain't it that an Innovation is a child of creativity?

This is the part where the comment does what I refer to as playing with words. I do this a lot myself. Playing with words to confuse the person on the other side during an argument is an interesting technique we learnt during our debate lessons in school. Let's play with words, now; shall we? Ever heard of proverbs like 'Necessity' is the mother of invention'?  You need to be able to define 'why' you are innovating whatever-it-is-that-you-are-innovating before you innovate. 

On the other hand the comment doesn't really explain how asking 'why' kills innovation or creativity.

The History that I know and was taught in school, tells me that most innovations have constantly happened because some kick-ass-guys (and girls) with really smart brains were able to tap into genuine needs and wants of people. After they did that they were able to answer 'why' people will need or want what is being invented or innovated.

Software History that I've been a part of during the early windows days has taught me that there have been a few products which were built with the 'why not' mentality and most those that I can think of have failed miserably. Ever heard of Microsoft Bob? When you say 'why not' and try to replace your desktop with a barking dog who is not even very funny, you really don't expect your customers to put up with your idea of something being 'cool' just because you asked 'why not' and decided to go ahead and build it anyway.

37Signals have been sited by many as leaders when it comes to recent day innovation in software and they have a one line “why” attached to every single product that they build:

Notice the word 'why' in the quote? These guys have given a lot of innovative products to the world and the basic premise on which their products are built is asking 'why' before they start building the product and then asking the same 'why' as every feature they add.

When you’re hooked on with the idea of building something, being asked 'why' seems like an attempt to kill your creativity, which is exactly what the comment seems to make it sound like, but more often than not that is clearly not the case. Creativity and innovation happen by constantly asking yourself 'why' not just saying 'why not' and doing things even before the 'why' has been answered.

The idea that asking 'why' kills creativity is blatantly wrong. Simple.

> That's why we hear of companies giving "paid" time to their staffs for their own creative projects (things that company hasn't seen yet, don't need either....but still they care for).

This is where I feel that the comment really mixes up Freedom, Process with the whole 'Why Vs. Why Not' thing. I will assume the comment talks about Google which is often sited as a popular example of a company that gives twenty percent free time to employees to chase their dream projects.  

The first time I heard the idea I loved it. I went out telling everyone about it. I really think that every company out there, that can afford it, should do it; companies like 3M had done it way before Google Started it. I personally recommend it highly. Having said that we need to remember that the basic assumption here is that the employees would have answered the 'why' themselves.

Everyone loves Google; me included. Having said that, I've never been at Google to see for myself how things are. While, it's perfectly ok to learn from these companies and get inspired it's also important to remember that how you do things is not about how Google does them.

I know these things sound perfectly glamorous when you hear them but it may or may not be as glamorous in reality as it seems:

On the other hand take a look at any Google Products including the search engine we all love and YAGNI is evident in every single part of their design. Do you think they can't afford to make a fancy looking User Interfaces for their products?  Obviously not. Simply put, their User Interfaces are simply sticking to YAGNI. That is what sets them apart.

Bottom line, I’m sure Google would have pulled the plug on this who free-time-thing if their employees were busy building BOBs  in their free time. Google continues this practice because Google Employees come out with Google Maps which provide direction to people and Orkut which helps friends connect with each other in turn building communities. All Google Products built on free time or as experiments have a core cause of existence and answer the 'why' very-very distinctly; and you know what? They follow YAGNI too! Every single one of them that I have seen so far does.

> The world will not end if new innovations are not born. The world is running & it will. People will take birth, people will live happily ever after, and they will die to rest in heaven. But we have innovations to ease our life, to make it a little better, a little easier.

This is the point where you feel like literally telling Rohit that he needs to slow down. Here's my response to this line in the comment:

Here’s how Wikipedia defines innovation:

Necessity truly is, the mother of invention and putting invention into practice like it has never been put before is called innovation. When you can answer the 'why' people need what you’re building chances are you are on to innovating something; if you can't, there's a high possibility that you're wasting your time and most probably their time as well. You know what? Unless your users can answer 'why' they should use your application or even read your blog; they just don't care.

Scott Berkun’s Video on Myths of Innovation which he gave at Google is interesting. It's interesting because Google is often sited by many as Mecca of innovation. The First Myth Scott breaks in the video is that innovation is absolute. He explains that innovation is in-fact, relative. In the video he explains that Innovation is the process of implementing an invention depending on the 'needs' of people.

His example is simple. Bringing electricity or water to an area which doesn’t have it is innovation for the people who live in that area even when most areas in developed countries around the world today, might not consider it innovation.

Asking 'why' people will need what you're building is the fundamental building block of innovation.

> We never needed iPod, we enjoyed listening music on a heavy, fat & ugly looking gramophone player. But then we saw evolutions. And now, iPod is in everyone's wish list.

Read this part of the comment again; seriously; Do it. Read it again; slowly. It’s ironic because it’s a question which answers itself.

Apple had a concrete answer to the 'why' everyone needs an iPod. Because the gramophones were heavy, fat & ugly. There. The question answers itself. Simple. On A side note, who is saying don’t build iPods, Eh? Apple had very good reasons to make the iPod; changing the way music industry works was one of them.

Now, Let's throw in some facts, shall we?

The comment picks an interesting example. The iPod.

I love the iPod. We all do; but for the not for the reasons comment sites. The comment almost seems to make it sound as if a couple of really hip-and-happening teenagers got in a room and said 'why don't we build a MP3 player' and then they suddenly started off building everything they could and changed the world resulting in an iPod to emerge out of nowhere. In a real world where I live, innovation is not that easy. In fact, Apple uses YAGNI extensively in their products which is what sets them apart. Ever wondered why most iPods don’t have a FM Radio? Dale Jensen explains:

Innovation by Asking 'why' and then sticking to YAGNI, simplicity and class; that is what sets Apple apart.

By now if you haven’t noticed how grossly wrong the comment is in its premise, let’s talk about MacBook Air, one of apples latest innovations, which they prefer to call 'Thinnovation'

Apple is surprisingly disciplined about asking themselves 'why' even before they add hardware to their latest notebooks. It lacks an optical drive, has very few ports, has internals that cannot be upgraded and lacks a swappable battery. As a commenter describes:

Apple could have said 'why not' and have easily decided to slide in that FM Radio in iPods and slide in those few extra ports in Mac-Book Air; but YAGNI to a large extent, is what makes Apple Products so desirable, classy, appealing and 'innovative'. Most people see Apple and Google as these cool and happening companies and don't even realize these facts. Of course these are cool and happening places, because they have the self discipline to constantly question everything that they indulge in.

> "Needs are created".

Who’s arguing with that? But if you can’t say why people will need what you’re innovating; people probably won’t. Create the needs, but answer 'why' they will become needs and 'why' others will need what you are building before you go in a dark cave and start building something. If you can't then how do you even know it's a 'need' that you're creating and not just crap?

> "When you ask others 'why?', ask Yourself 'why not?'. Most of the questions will be answered automatically."

I could rephrase this as:

When you ask others 'why not' answer the 'why'. Most of the questions will be answered automatically. Call me arrogant, but I make a personal hobby out of playing with words and philosophies. I practically have a cupboard full of books which talk about the meaning of life, universe and everything. I read them all night. But you know what? When it comes to getting down to hard realities of life, The answer is 42!

On a serious note, while these words and ideas are nice to play around with, truth is that simplicity, personal commitment, personal discipline, continuous focus and hard work lead to innovation. Notice that I use the word 'personal' (not externally imposed). Unless you can concretely ask yourself 'why' you are doing something and then answer that why, the commitment and and focus doesn’t happen magically. Saying 'why not' and adding features randomly often takes away the simplicity which is often the soul of any innovation.

The comment seems to resonate a tone that there are two things you can do; you can either meet your dead-lines and meet processes or be innovator and change the world. In the real world however, a lot of innovations are often created because of real life limitations. The guys at 37Signals explain:

While it's easy to say, that you had a time-crunch and other limitations which is why you couldn't innovate, another way to look at it is that limitations often breed innovations.

> Why vs Why Not" is always useful, for everyone. Because that helps, helps grow

Do You know what helps people grow? The smack down learning model where you basically start with strong opinions are weakly held and throw a few punches at each other. On a serious note, I really believe that it's one of the best learning models out there which is why this post wears a highly opinionated tone. 

The comment seems to mix up innovation, creativity and a lot of other things with asking yourself 'why' and seems to create a confused mesh of ideas. It's great because it keeps a lot of discussion points forward but it's confusing and misleading. I cannot get myself to agree on it because it's based on the premise that asking 'why' is anti-innovation which of course is blatantly wrong. That's where it starts and then it goes all over the place about how asking 'why' prevents changes from happening on this planet; which again, is clearly not the case.

The comment seems to break the world into two kind of guys; the we'll-change-the-world guys who go around doing things without answering 'why' they are doing them in the first place and build random stuff and change the world and the why-are-we-doing-this guys who basically don't innovate, stick to the process and get projects completed. That's where the premise of the comment goes wrong. The comment basically misses the fundamental point that you can constantly ask yourself 'why' in a fun way, continue innovating by answering those questions relating to 'why' and be pragmatic.

That's how the folks at apple Keep the iPod simple and not get carried away by their desire to build cool features. If they didn't restrain this desire, you would probably have hundreds of  features in your iPod and you probably wouldn't love it all that much.

That's how folks at Google keep their User Interface Simple. That's one of the reasons why they beat Yahoo which was then the dominant search engine. They did by using YAGNI and simplicity to their advantage.

Most innovators are surprisingly clear about answering questions pertaining to the 'why' when it comes to their innovation. 

I’m standing by the premise that answering the 'why' is much more important than just saying 'why not' and then building stuff. I'm standing by this premise unless of course someone out there can let me know 'why' I should change my premise.

You don't ask why, you don't get innovation. It's that simple.

Disagree? Let’s have a smackdown battle of thoughts.

When you’re working with 501 developers you’re faced with a huge number of problems and your chances of entering the infinite loop of failure are almost certain.

On the other hand however, working with enthusiastic young and budding developers doesn’t always guarantee success. Of the many mistakes that even young and enthusiastic developers often make, the 'Lets-Build-This-Cool-Feature' Syndrome is one of the most lethal ones.

If you’re reading this blog, chances are high that you are, more probably than not, passionate about software development. You have this itch to create software with cool features and user interface that would have people drooling over your software and clapping out loud when they see it.

You’re probably busting with ideas and features right now as you work on your product and believe me that’s a good thing. Not a lot of people in our world have this un-ending passion for software and computers; Having said that, the 'Lets-Build-This-Cool-Feature' syndrome can cause your project to fail just as fast as the 501 folks would have caused it to fail.

I love writing code and spend almost quite a few hours doing that. For the rest of the day, my job demands that I get involved with reviewing software products built by the organization and give ideas and direction to the product teams.

Recently while reviewing a system which is supposed to help organizations develop and maintain taxonomy of their skill-sets; I came across a small feature which allowed people to add every single page in this system to their social book-marking system. It was like an ‘add-to-your-favorite’ kind of thing.

My shocked reaction may have come as a surprise to the entire team as I criticized the feature’s existence in the system heavily and questioned the team on why the product needed that feature. 

The ‘Why’ was answered by a rather passionate software developer's argument which was on the lines of – ‘Why not?’

This post is about answering the ‘Why not’.

The Single Word Answer to the 'Why Not' is simple. It's called ‘You-Ain’t-Gonna-To-Need-It’; also referred to as ‘YAGNI’ in the software development world. Wikipedia defines YAGNI as:

In software engineering, YAGNI, short for 'You Ain't Gonna Need It', suggests to programmers that they should not add functionality until it is necessary. Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."[1].

Simon Willison describes how he puts YAGNI to use in his blog:

You Ain't Gonna Need It states that you should always implement things when you actually need them, never when you just foresee that you need them. This is great for controlling feature creep; the moment one of us says “we might need that later” the other says “YAGNI” and we can move right along.

The folks at 37Signals are much more passionate about building features only when they are genuinely needed:

Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it. Just try to take a released feature away from customers and see how pissed off they get.

With products like Base-camp, Backpack-It and almost all their other products they seemed to have lived up to their words:

Make each feature work hard to be implemented. Make each feature prove itself and show that it's a survivor. It's like "Fight Club." You should only consider features if they're willing to stand on the porch for three days waiting to be let in. That's why you start with no. Every new feature request that comes to us - or from us - meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.

In fact, Ron Jeffries takes YAGNI to the next level. He proposes that developers should use YAGNI even while writing code:

You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because "we’re going to need it". Don’t write getters for other instance variables because "we’re going to need them".

Scott Hanselman has similar very interesting post on why every class you write shouldn’t be marked public. The post has a quote that explains what can be otherwise described as a You-Ain't-Gonna-Need-It practice:

Scotts [sic] philosophy and that of many people at Microsoft (and many component vendors - Infragistics being another great example), seems to be to mark everything as internal unless someone gives them a reason to make it public.

I do understand almost all of us who feel passionately about software development, feel this yearning desire to build that feature which will have our users drooling and clapping, but 'growing up'  as a developer, also means understanding that it’s equally important to resist the temptation of building cool features or writing more code, especially when the features or lines of code can't justify their own existence.

While asking yourself if you want to build that feature, write that piece of code, write a setter for that variable or mark a class as public, answering the 'why-you-need-to-do-it' becomes much more important than just blatantly asking ‘why not?’. Answering the ‘why not’ is easy: it's usually 'because you probably aren’t doing to need it'.

Unless you can answer the 'why' easily, that feature you’ve been thinking of building and have been very excited about is just another ‘cool feature you probably aren't going to need’.