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’.

Let's pretend I started writing TacticSheet six years ago. If you would have walked up to me back then and asked for a quick explanation on how the login of TacticSheet works, I would have presented you with a document called 'module specifications for the login use-case' containing multiple diagrams, some of which, would have looked somewhat like:

But then I didn't start building TacticSheet six years ago. I didn't even think about it back then.  Methinks my not attempting to start with TacticSheet six years ago definitely had something to do with the diagram above. Humor me. I have a point to make. 

Six years have flown by, faster than I thought they would ever fly by. A lot has changed in ways I would have never thought it would change. Six years ago I encountered my first 'successful failure' which to a large extent, changed everything. Since then, I've come full circle. Today if you walked up to my office and asked me how TacticSheet authentication works, I would probably just take you to a white-board and draw something like this:

Six+ years and one colossal failure later I learnt my lesson which taught me how to use a white-board. I learnt that design isn't all about locking yourself in a cubical and writing fancy documents.  I learnt that Project Management isn't about building Gant Charts and then going around the office asking people what the status is. I learnt that If I was ever going to work with (I'd rather not use the word 'manage') a team of smart developers I would have to roll my sleeves and at-least try and write code which is somewhere close to the code the rest of the team was writing. More than all of this, I learnt the art of 'trying' to express myself using a language and tone that others could connect to and understand. An art that even the most veteran of all consultants in our field lack.

As a part of my job, I talk to so called software developers, programmers and consultants all around the world. I interview them, discuss their profession with them and more than anything else I observe them; a lot. If there’s one thing I can tell you about most of them, it’s this:

Most of them are full of crap.

Why?

Because they complicate things; Un-necessarily.

FTC, UTC, LDD, HDD, SRS (the list is really end-less but I think you get the point); Talk to a group typical consultants about their projects or what they are up to and it’s not un-common to come across at-least a few of these three letter acronyms within the first ten minutes of your conversation.

Most of them seem to light up when they use these. God-forbid, if you cannot connect FTC to Functional Test Case, or HDD to High Level Design Document, you would have given them a deep sadistic pleasure of being more knowledgeable than you are.

Turns out, I’m not the only one who has a problem with these crappy attempts to complicate perfectly simple things; like a test-case or a design document for-example.
Scott Berkun describes why he hates most software consultants:

With armies of consultant, clueless about craft of building software, complexity in the way they communicate is something that's bound to happen.

The infinite loop of failure often moves around a vicious eco-system. If consultants who are iterating in this loop are using excessive jargons it’s probably because the entire eco-system encourages them to do so. In his same article Scott Berkun describes how the eco-system encourages this crap:

Do you, dear reader, use complicated acronyms and jargons when you talk to your clients or fellow developers? If you do, ask yourself if you are using them just to impress or intimidate the person you are talking to; or are you using them for a greater self esteem and feeling better about yourself? Either ways, whatever be your reason, if you are using too many jargons in your conversations, stop; stop using them right now. Stop before you are perceived as a consultant who is full of crap.

I have quite a few friends who happen to be doctors and family physicians. When it comes to picking my doctors or physicians I judge them by their ability to say ‘I don’t know’. When a doctor or a physician is talking to me about my health and what's gone wrong with it I expect that he takes time and explains it to me in a language I can understand; even if it's just minor stomach ache.

If he doesn’t know what’s wrong with me and decides to give me a treatment based on a gut feeling or instinct, that's ok too. Either ways,  I want to know and I want to be told in a language I understand.When I come across a doctor or a physician who lives in his ivory tower of medical-terms or jargons and uses them at every opportunity he gets, I turn around and run. I perceive this as a signal of incompetence and immaturity.

When you talk to intelligent clients, they are judging you; all the time. Just like we judge doctors and physicians. They’ll respect you and connect to you only if you can explain the most technical terms and concepts to them with simplicity; using a language they understand. Insult or intimidate them with your crap load of jargons and they'll be gone way before you know it.

It took my six years to develop a shamelessly-thick-skin and then put it to use in the real world. Now every time I hear a self-made-jargon or an acronym I'm not aware of, being used by anyone, I stop the discussion and ask the person using the jargon to explain it. I do it over and over every time a new acronym that I don't understand is used and I do it shamelessly.

At times, the person using the jargon feels highly irritated and after being interrupted a few times, stops using them. Other times, he draws a conclusion that I'm an alien with a third eye who is not good enough to be a part of the discussion and decides to ignore me completely and focus on other 'wiser' participants in the discussion who are as equally lost but would hardly ever admit it for the fear of lack of being intimidated.

I started this blog for developers like me. More specially put, .NET developers. When I analyze my traffic now-a-days it's easy to analyze that more than 50% of the regular readers of this blog are not .NET developers. Every now and then I'll get praises and criticisms about this blog. I love them both; but the praises that I've enjoyed the most are the ones, where people have told me that my blog is read and understood even by non-dot-net-developers including folks who are not technical.

Off-course, depending on the nature of the post it’s not always possible to cater to a completely non-technical audience, but I try my best even to make sense to a non-technical audience. Any complements on the lines of this blog making sense even to a non-technical audience are complements I love and treasure because they remind me that I'm not a Jargon freak scaring people away through the crappy technique of intimidation.

Next time you hear a consultant using self-invented-short-forms-and-acronyms and you are clueless about what he is trying to say, give Mr. Jargon a gentle reminder that there 200,000 words in the English language and if Mr. Jargon cannot say what he is trying to say in those 200,000 words, what he is trying to say is probably not worth listening to. Net-Net, either give him a gentle reminder about the vastness of the English language, or maybe, try using the Consultant's Jargon Generator, beat him at his own game of stupidity and then tell him how you did it. I prefer the former. It's much more polite.

If Mr. Jargon cannot simplify and explain what he is trying to say like he were explaining it to a teenager, he is probably just full of crap and probably isn't worth listening to; I don't care how many FTC's or HDD's he has written in his life. Seriously.

The Internet is quite literally littered with articles on how Google considers it's employees really important and how beautiful life is at the GoogolPlex. There are a huge number of articles out there describing how Google is very selective on who they pick and how Google offices around the world take care of their employees:

Folks at 37Signals are also particularly articulate and bold about expressing their opinionated approaches and techniques of how they focus on recruiting smart employees rather then huge number of bodies:

Companies like Google and 37Signals have made it big, in completely different ways and yet somehow managed to retain the 'magic touch of being small'. These companies have emerged as companies which have achieved success in a distinctly different way. To add to that, they, much like anyone else who is successful, are particularly un-ashamed about flaunting their success and sharing nuggets of wisdom with  anyone who cares to learn how successful companies are built and run.

No doubt, the Internet is quite full of articles based on perceptions and ideas on how successful companies are built and run.

If you’re a round-peg-in-the-square-hole, these companies and how they function will continue to sound like a perfect validation of how you think and function. Agile, Scrum and philosophies like embracing the truth of software development and getting real will make perfect sense and a huge appeal to you when you read about these concepts and how these companies have had success with these methodologies.

On the other hand our industry also has companies that run huge body shops across the globe. Companies that have always been a known to be cultivate symbolic armies of consultants, bred through a well defined process and rapid growth measured purely by the number of 'resources' hired:

These are companies that genuinely and truly believe that a process oriented approach and processes like SEI CMM or RUP are an answer to how software is built. The fundamental principal these shops work on is that If you can somehow stuff fifty resources in a tiny room and make them follow a process you can get software built.

If you’re an I-have-earned-my-degree-from-best-college-and-I-wear-a-suite-to-office kind of individual, these companies and how they function will always sound like a perfect validation of your beliefs and how you get your projects done. Big Design up-front, RUP and SEI-CMM will make perfect sense and appeal to you when you read about these processes and how these companies has had success these processes.

Like it or not, the Internet will always be littered with articles from two kinds of companies. Companies which innovate and change the way software is built and companies which out-source and build software needing huge number of bodies and very little innovation. Given that you're constantly going to be bombarded with articles and success stories from both camps, how do you pick which camp you belong to? 

This is one question the guys at 37Signals solve rather easily when answering the question if their book is for you:

One of my first projects I was involved with as a young engineer was a implemented through a deadly blend of RUP and CMM. As much as I was learning the tricks of defeating the client and getting my Project UAT done successfully with the help of CYA documentation, there was something that constantly 'felt wrong'.  When I first read about Agile and Particularly scrum I was hooked. It 'felt' right.

Ideas like putting people before process, working with smaller teams which can sustain themselves, doing away with un-necessary documentation and bureaucracy and the like, clicked. It was a reconfirmation of what I always believed in and gave me enough reason do what I always wanted to do as a young engineer, which is: have fun and build software that, for a change, works. That is exactly what I'm doing even today. Every day of my life.

Did a book or a web-cast on scrum change my life and convince me to go the Agile route? Not Really. I think I was already sold to a particular way of building software way before I picked up my first book on Agile. The books on Agile and web-casts on scrum were an excellent an enabler, reconfirming my faith in what I already believed in.

After sending countless links to young and budding developers, and traditional managers around the world, I finally realized a simple fact of life: The whole CMM Vs. Agile thing and which one you pick for your project is usually deeply rooted in your personality, character and your past experiences including how and why you entered the business of building software. You've probably picked your methodology way before you put your first step in software development world and way before you even heard about these methodologies.

The confused ones, willing to learn and move will nudge easily. However, for a traditional manager who truly believes in the power of the Gantt-Chart, trying to nudge him over to the agile side is usually a waste of time and energy on everyone's part.

Yes, confirmation from someone like Google or 37Signals or anyone else who has made it work by trusting people over process helps, but in the end which methodology folks will follow will largely depend on their way of looking at things and character. Remember, it's not about Google, 37Signals or your software development process. It's more about your personality, beliefs and above all, yourself.

Michael Lopp's book Managing Humans has a classy introduction done with an elegant use of pictures. Besides it's elegant front cover and a classy promotional web-site, what I particularly like about the book is the keep-your-feet-on-the-ground tone filled with humility that resonates throughout the book as you read it.

For a book which is supposed to teach young and budding managers to how Manage Humans and not just develop your coding skills, Michael's advice to young managers, that they should continue coding even after becoming managers, comes as a pleasant surprise.

Michael, in his book, seems to address multiple concerns budding managers have when continuing to write code for a small part of the day after they get their first promotion to a managerial role. Of all these concerns, he addresses the concern that managers who write code end up confusing their team and make the team wonder if they are a managers on a developer, rather elegantly:

Good. I mean it. I’m happy you’re about to confuse your team by swimming in the developer pool. The simple fact is that well-defined roles in software development are fading. User interface guys are doing what can only be called development in JavaScript and CSS. Developers are learning more about interaction design. Everybody is talking to everybody else and they’re learning from each other’s mistakes, stealing each other’s code, and there is no reason that a manager shouldn’t be participating in this massive global cross-pollination information cluster-fuck.

As a part of my day job I interview countless budding-managers who stopped writing code at the very first opportunity they got. These are folks who have barely been promoted for less than a couple of years and they decided to quit coding the day they got that promotion letter; even before they made it through leading a couple of successful projects or proved themselves as a very good people person or a decently acceptable manager. Talk to them for a few minutes in an interview and invariably the same story evolves:

Fred was desperately looking for a promotion. Fred 'somehow' managed to get promoted. Fred stopped writing code and locked himself in an ivory tower from where he looked down upon all who write code. Needless to say that Fred also started believing that his job role demands that he goes around the office with a lot of serious looking printouts of documents in his hands, suggesting everyone follow the processes he is laying out, asking everyone what the status of their task is and periodically yelling at developers to make them work harder.

So, at the first opportunity Fred got, he quit coding. He left it for good! After all he had to grow in his life and in order to do that it was really important that he stopped writing code all-together, right?

Wrong.

Steve Yege's advice for folks who desperately want to quit coding at the first management opportunity that they get is rather strong and direct:

Witting some code or participating and contributing actively in process of software development during the day, even if your organization expects you to just manage teams, has it's own set of advantages. Michael, in his book, advices managers on continuing to write code and having fun creating software even after they receive that promotion. Writing code and being actively involved with the project, Michael feels, can help managers communicate better with their teams:

I’m not wishing confusion and chaos on your team. I’m actually wishing better communication on it. My belief is that if you are building the product and touching the features, you’ll be closer to your team. But, more importantly, you’ll be closer to how software development is constantly changing in your organization.

Jeff Atwood questions how important writing code really is:

As much as it might sound that Jeff gives more importance to abilities that complement coding besides writing code, even Jeff seems to think that all these activities combine are largely useless if you are not playing active part in the process of creation:

Writing a little bit of code also acts as a good reality check on how good at building software you really are. I've often said that the confusion and turmoil in our profession makes writing software very similar to fighting a war. If you're going to learn the art of leading an army in a war why not learn it from some of the best warriors in history:

Let's face it. While fighting a war things are bound to get ugly. If you're not prepared to go out there and take a few shots yourself do you really expect your team to follow you and help you through the difficult times?

Even if you don't write code that runs on production, at-least participate in some form of supportive activity in the project and own a task. If nothing else, write a few unit tests to help your team improve the quality of what they are building. If you're not supposed to code actively in your project, start a small open source project and continue to hone your coding skills there.

Bottom line: Do whatever it takes to make sure that you're speaking the same language as the rest of your development team and not mangementese.

If you're a budding manager who's just got his own team to lead (not manage), a brand new project to run and if you're wondering whether you should stop writing code completely and just focus on your managerial skills, here's my advice to you: don't even think about it.

Remember, how to develop software is changing. Now. Right under your feet, this very second. And it might be changing very silently and subtly but it's changing faster than most of us think. If you're going to lead really smart software development teams, not spending at-least a few minutes a day writing code and failing to learn how software development is changing and evolving can be the single most devastating thing for your career.

Sure, learn how to manage humans and how to write about code besides writing code. I've myself advised individuals to turn themselves into a one man army. But even as you learn these other skills, don't forget to dedicate a few minutes a day to the bits and bytes when you roll your sleeves and write better code than what you wrote yesterday. Remember, at the end of the day Gant charts and CMM won't get your projects done or make you successful. Your own competency, your team's competency and your and your team's collective knowledge of how software development is changing and evolving will.

Some of the best managers I've worked with are folks who have rolled their sleeves and helped me 'on the field' when I was fighting with learning a new technology at a client's office. They've joined me in the battlefield and fought side by side with me. Quite literally. Other's have gone out and taken care of doing requirement sessions with the clients and writing and formatting use-case documents when we were running short of business analysts.

Quite a few of them have owned modules of code while I've also seen a few of them relentlessly tweaking HTML or giving ideas on usability and end user experience of the applications. Yes, I've been perpetually confused about whether they are Managers, HTML writers, Business Analysts, Mentors or Developers; But none the less, I've enjoyed working with them as much as I enjoy working with a smart bunch of developers.

So you got your promotion and your business card now reads 'Project Manager', Eh? Good.

Now go ahead, open that IDE and write some code Mr. Manager. It's nothing to be ashamed of. On the contrary, it's something to feel proud about. Seriously.

What's your favorite web-site?

Over the past couple of years I've asked this question to a countless number of people in presentations, meetings, seminars and in day-to-day-discussions. Most of them have been programmers and most of them have responded with an answer that shouldn't surprise you.

Google.

Technically speaking, Google is not a web-site. It's this thing, that makes other web-sites exist; but if you want to call it your favorite 'web-site' just because that's where you spend most of your online time, go ahead and call it your favorite web-site. Whatever makes you happy.

None the less, the fact of life is that Google is an awesome content-enabler. Being the kick-ass search engine that it is, If the content is out there, it crawls it, indexes it and makes it available to you when you need it.

Ok, that single sentence above is the soul and essence of this entire post. Seriously. Take a pause. Read the above sentence again. Slowly. Did you get it? Did you get the hidden punch word in that sentence? Let me clarify.

'If the content is out there'. Or should I say, if 'we' (the collective sum of all users who use Google and this thing called the Internet) 'choose' to put the content out there.

Of-course, like a lot of Internet users, you could continue to assume that 'someone else' will put the content there or Google will just get you the content even if it's not there as long as you continue to call it your favorite web-site; but then, in the long run, that won't work.

Here's how Wikipidea defines a leech:

Modern protocols and communities ban a leech from getting the benefits of the community once a leech is discovered. But Google and the Internet in general, are a lot more forgiving which is probably why a lot of us don't even feel guilty about not contributing to the wealth of content that's available online. We continue leeching away, day after day.

If you fall in this category of non contributors, may I suggest that you spend a just a tiny bit of your time to take a stock of relevant, useful and valuable content you've contributed online, that Google is indexing and making available to folks who need it?

No, I'm not talking about your Orkut or Facebook Profile which allows people to Google you by your full name or your blog where you primarily write about how much you love your dog, how much the world sucks and how much beer you had last weekend. Don't get me wrong. There's nothing wrong with writing about all of that. But that does not count as a valid contribution to your favorite search engine, the Internet or to the world in general.

In my previous post about being opinionated, someone commented that caring about others while earning your own bread and butter is difficult and not everyone is capable of expressing their opinion articulately even if they might be able to have their own opinions. I also got a few similar emails which essentially said the same thing. Here's what I have to say to all those reactions:

Bullshit.

No seriously, not being able to express your own opinions articulately in a blog post is completely fine and acceptable. But then, you can still contribute. Here are multiple ways of contributing wrapped up in a are-you-a-leecher-test. If you answer no to all of these questions, chances are, you probably are a leecher:

1. Are you regularly spending some time in technical user-groups or forums asking intelligent questions or answering them?
2. Are you writing a technical blog where you are sharing your findings and your ways of doing things with others?
3. Do you own, work in, or contribute feature patches in an open source project?
4. When you find a bug in an open source project that you are working with, do you report it elaborately, try to suggest a fix or maybe even send a patch with the fix?
5. Do you write for code-project or any other technical web-sites?
6. When you buy a new book or a new cell phone do you write and post your reviews to help others?
7. When you read a blog post that moves you or you disagree with do you care to leave a comment that adds value to the ongoing discussion?

As much as I disagree with 'Shaun The Sheep' and his comment on my earlier post, here's my official reply to his comment:

Scott Hanselman also invites 'lurkers' to join the on going conversation on his blog:

Commenting on blogs, is just one way to participate and contribute. Keep an open mind and I'm sure you'll get countless opportunities to add to the wealth of information that's out there. You can add your thoughts and perspectives to the variety of discussions that are going on in the whole wide web. You'll be amazed at how quickly you can feel connected to individuals you have never personally met and communities you have never physically been a part. You'll also be amazed at the wide open holes where information is just not available out there or missing on the Internet.

To some of my regular readers, a few of my troubleshooting posts might sound out-of-context to the over all theme of this blog. However, I've seen countless individuals come to this site through a lot of these posts, simply because the information wasn't available as easily as you would think:

I've been amazed at the lack of information that Google has provided for problems that I've had in the past. Was it because Google was incapable of crawling and getting to this information or was it because this information just wasn't there? Allow me to Illustrate:

I could go on with countless examples from this site itself but that's not the point. The point I'm really trying to make is that the Internet is not this perfect treasure of information we usually think it is. There are missing holes which we, dear readers, can fill every-time we find them.

It's important that as we continue to 'Google' stuff and get some information or content for free, we also take a stock of how much value we have added to the whole online eco-system. Every time you see a conversation going on in a blog somewhere and you feel you can participate and add value, take some time and give in some effort to do so. Every time you have an answer to something you can't Google easily, document it and give Google a chance to index it. If you don't, the future of your favorite search engine and the Internet will not be as bright as it is today.

Jokes apart. Seriously, if you've written something (software, code, articles, posts, answers to questions in forum or anything else) that's free and has helped a few other individuals you've already joined an elite group of contributors in the online eco-system. Congratulations! If you haven't, may I suggest that you stop being a leecher? Start thinking of ways of participating and contributing. You'll be amazed at just how many people are listening and willing to participate with you.

To be honest, the world or the Internet won't really come to an end tomorrow morning if you don't contribute or participate. There are a lot of discussions happening out there and if you play the role of the shy loaner sitting in a corner, who has nothing to say, give or contribute in any small or large way, you are the only one who is going to lose out in the end.

I've already listed multiple forms of contribution in the are-you-a-leecher test above. If you are a leecher, pick one of them or just find your own form of contributing and start now! And by the way, for your own sake, stop saying you've got nothing to say or contribute. That's the single most lamest excuse I've heard for not contributing. 

Now go out there and write that post you've always thought you would write, start work on that open source project you were always thinking of working on or releasing, answer a few questions in a user group or do whatever it is that you are comfortable doing; but do 'something'.

The Internet brings the whole wide universe to your desktop. Don't just leech off it! Add to it, give it a whole new perspective and leave your mark upon it. Make a dent in the universe that sits behind your monitor; in whatever big or small way you can. I wish you luck.

Legendary author Steve McConnell, in his book, Rapid Development - Taming Wild Software Schedules,  gives a lot of importance to the People factors in software development:

When I was a young and budding engineer, I heard quite a few of my seniors and traditional managers be-little the activity of writing code as something 'anyone can do'.

A few of them, expressed their surprise at my desire to work with and hire smarter folks on the teams. They often remarked that if my design was detailed enough and if I had my documentation drilled down to the smallest detail of every class, anyone should be able to write the code and get the system built. 

Back then, for them, and a lot of huge software development body shops around the world, developers were quite literally 'resources' you could hire to write code.  

One resource was supposed to be very easily replaceable by any another as-and-when needed.

As much as the picture might seem funny, most body-shops around the world, even today, are blinded by the belief that if they have their CMM, RUP and Gant Charts in place, who writes the code does not matter much. Most developers today, are roaming the streets with the symbolic 'will code for some more food' sign in their hand as they hop from one job to another and most companies are picking up these developers off the road. 

Lack of respect for kick-ass programmers, Inability to differentiate the flock of sheep from the thinking brains, organizations believing that Gant charts, RUP, CMM and BDUF approaches and methodologies can make or break a project, not programmers and their competency, is in fact, to a large extent, responsible for brining the business of building software to the sorry state that it is in today.

Steve McConnell in his book uses analysis from NASA to place a tight slap on the face of this traditional thought process:

After 20 years of experimentation on live projects, researchers at NASA's Software Engineering Laboratory have concluded that technology is not the answer; the most effective practices are those that leverage the human potential of their developers.

Of-course you can get 'anyone' to somehow write some code and get something that looks like a system built; but if you don't have a self sustaining team of thick skinned programmers you are bound to fail infinitely. I am completely on Joel Spolsky's side when he says that primary cause for most failed projects are incompetent teams:

Quite obviously this describes why I had heard so many complains about the client changing the requirements, the design not being detailed enough and the use-cases not being elaborate enough, early on during my career as I worked on one of my first 'successful' grand failure. The simple fact of life was we as a team were incompetent and instead of fighting my incompetence I was being taught to hide behind a thick curtain of processes and defend it. Thankfully, I ended up seeking refuge in think-skinned shamelessness. Years later, I'm damn happy I did. 

Even today, when I go into a client's offices or multiple other organizations and see their team of developers complain about the requirements changing, about lack of process and about lack of documentation, I get my first hint of what's really wrong. Almost invariably, it's the team that needs more help at becoming competent, coping up with the changing requirements and shredding off excess baggage of stupid processes. 

Bruce Eckel has done quite a bit of these postmortems that Joel talks about and had the courage to explain the root cause of all software development related problems:

Jeff Atwood does not hesitate to go even as far as saying that whether your project will succeed or fail depends on whether you like your co-workers or not:

Steve Yege, is also all about developer competency and competency of teams much more than processes. He thinks even Agile is an overkill:

Surprisingly, even the Agile Manifesto to a large extent agrees with Steve and puts people ahead of process and recognizes the importance of having a motivated team of talented programmers and giving them the best of tools:

These are in-fact, words of truth and wisdom. In all aspects of life, trust is in fact really the hardest thing to give. No wonder most body shops around the world find it really difficult to provide trust to their employees. No wonder we are spending countless man-years building support for law-suite in our documentation and trying to replace quality programmers with stupid processes and 'cheap resources'. No wonder traditional managers around the world, like to nurture beliefs that given 'x' number of 'resources', irrespective of who those resources are, they can get a system built in a finite pre-determined number of man-days. 

On a side note, if there is one term in software development and project management terminology I grossly dislike it's the word 'resources'. It seems to club all programmers in a very generic pool almost making it sound like programmers are 'things' or a flock of sheep. But we all know kick-ass programmers are way more than a flock of sheep.

Who you work with, to a large extent affects how successful your projects will be and ultimately how successful you as an individual will be. If you're a manager who was reading that big fat book on managing projects using CMM and RUP and hoping to hide behind the process curtain if your project fails, sorry to shatter your dreams, but you know what? That won't work. Not in the long run. Do this for a few months and I'm sure you'll cultivate a tendency to fail constantly and blame it on the lack of process. For a change, help yourself by reading a slightly different blend of books. It might help.

On the other hand, if you are a programmer who is a part of a self managing team that's shipping quality software; there's a high possibility that you'll never get to buying and reading that big fat book on CMM and RUP. Yes, you'll make big fat new mistakes in every new project. But you know what? You'll tend to learn from them and get better and successful project after project as long as you keep working on your shipping skills.

Realizing and accepting one simple fact sets a successful pragmatic leader apart from a worthless manager sitting in his ivory tower: CMM, RUP and Gantt Charts Don't Build Successful Software. Kick Ass Programmers do.

Also, while we are at it; can we please stop referring to programmers as 'resources'? It's too generalizing, makes it sound as if all developers are exactly similar commodities that can be swapped for each other and more than anything else, to kick-ass programmers who are passionate about what they do, It tends to sound a little intimidating and condescending. May I suggest referring to them as programmers, developers or team members?

Venkat Subramaniam and Andy Hunt  in their book The Pragmatic Programmer make the devil and the angel play interesting roles by making them sit on the programmer's shoulder and letting them give him advice which the reader can choose to follow or ignore while working on real life projects.

As you would expect, almost invariably, the devil's advice represents the thinking of an immature, in-experienced programmer. Keep listening to the devil's advice and you can slowly lead your project into the state of uncontrolled chaos. Take this advice for instance:

On the other hand the Angel represents the thoughtful, self disciplined, matured and pragmatic developer, making your life a little difficult but your projects much more rewarding and successful:

Anyone who has been involved with even one single complex project and has got-it-done successfully, knows that software development is like fighting a war with multiple enemies (time, complexity, bad-communication and many others) hidden and attacking from multiple directions and fronts. Subtle chaos and confusion are a part of the game in our business.

So solider, you've worked hard for years; your god's have smiled on you and turned you into a one-man-army. You've developed a strong armor of thick skin and have carried with you, in your arsenal, weapons like simplicity, prioritization, quick iterations and the like. You have earned your client's trust and they walk with you as allies. You are proud of the small yet gallant army of warriors that walks with you and you are highly motivated to win your wars on as many fronts as possible.

But wait! You forgot to carry with you two very important members of your team. The Symbolic Angel and The Symbolic Devil from Venkat and Andy's book.

That's right. You heard me. You need them both. Let the angel lead you in the right direction but don't leave the devil behind. As you grow and mature, you learn to let your symbolic angel mingle and work with your symbolic devil. Growth is all about your angel learning and getting used to channeling your devil's ideas in the right direction.

The real trick is to empower your angel so strongly that she cannot be affected by the devil. At the same time, let her use the devil's obsessive compulsive advices for the good of your project.

I've had experiences of the Angel working on the Devil's advice and adding her own magical touch to produce some outstanding results.

Based on the devil's advice of bulldozing the entire project and starting fresh and the angel's magical touch on that advice, the Turkish proverb - “No matter how far you’ve gone down the wrong road you’ve gone, turn back.” was changed to “No Matter how far down the wrong road you’ve gone, find the shortest, safest and smartest way to the right road.” - you can see my symbolic angel and my symbolic devil working together and coming to this pragmatic middle path in one of my older posts.

Dave Winkler has his symbolic devil telling him that all software he builds is shitty and he might as well write some shitty code. But his angel tames his devil with practical pragmatic advice:

The Devil from Venkat's And Andy's book also advices:

This is by far the most lethal advice that can turn your project into a dirty political campaign and a direct quest for failure. However, with a little bit of magic which comes from the Angel's touch, we make this same advice work for our build management process.

At work when a build breaks, we find the culprit. Just to get the kick out of this whole thing, we quite literally call the exercise - 'finding the culprit'. Once the culprit is found, he gets an instant 'promotion' and becomes a 'build manager'. As a build manager he's supposed to fire three builds a day and baby-sit the build till someone else breaks it.

At one point we had jokes and bets going on who the next 'build manager' was going to be. We've also considered printing special balloons which have 'build manager' labeled on them so that we can stick them off the cubical of the current build manager.

We like to add a little bit of spice and fun to our build process and the devil's advice blended with the angel's magical touch does wonders! As funny as it may sound, every time we've introduced this technique, we have seen the number of build breaks go down tremendously.

Let there be pair programming between your symbolic angel and your symbolic devil. Let your devil get influenced by the good company of your angel.

Initially of course, your symbolic devil will hate it; but once tamed and under your angel's influence, he can end up giving you some pretty wacky and out of the box ideas!

To begin with you'll have to be really careful. If he does nothing else, as he begins to walk down with your troops, your devil will just act as a measure of what-not-to-do. As you continue to let him mingle with your angel and be influenced under her company, he will come up with ideas which can work wonders if they get your angel's blessing and magic touch.

Dear readers and fellow programmers, are you headed for your next big war with your army, your allies and your arsenal? Don't leave your symbolic angel and your symbolic devil behind. Your devil might be a big fat opinionated jerk but if tamed properly by your angel, you can still use him to your own advantage and kick some serious ass in your next big war.

The folks at 37signals are not particularly worried about sounding opinionated when accused of taking a black and white view:

With BaseCamp they have indeed proved the rest of the conventional world wrong by presenting their ideas using rather bold strokes.

If RoR is often referred to as opinionated software, it's because it was meant to be that way:

The same tone also resonates in the ASP.NET MVC team and Scott Hanselman's post which talks about ASP.NET MVC framework:

Clearly, this team is not trying to please everyone with the same stereotype music. They're targeting a specific audience that cares about writing quality code, taking pragmatic decisions and keeping things simple.

When you think of opinionated bloggers, Rory and Steve Yegge come to mind. Both of these guys are loud, direct and completely arrogant. Which by the way, is exactly what I love about their blogs.

Rory's site for example has a footer which reads - "I *own* this site, you loser" and Steve Yegge criticizes all development processes including agile when the rest of the world is going gaga over these methodologies.

Opinionated individuals causing serious damage and making big (or even small) dents in the universe are much more interesting than the usual flock of sheep grazing harmlessly in the fields primarily because these opinionated trouble makers tend to stand out and shine amongst the flock of sheep.

Contrary to the traditional belief, being opinionated and having that reflect on your life, your software or your blog is not a bad thing. In fact your opinions are what set you apart and help you stand out from the crowd.

Throughout my career I've worked with numerous junior engineers and a lot of programmers fresh out of college. Of them the ones that have stood out the most are not the ones who have the highest rank. The ones who usually stand out the most, invariably seem to have at-least two particularly common characteristics:

1. They have an opinion.
2. They are unafraid to express it.

My lamest work experiences have been with folks who tended to agree with everything I had to say, offered no arguments what-so-ever and then chickened out when it came to execution of ideas. Having said that for the most part I've been plain and outright lucky to have worked with folks who I can 'agree to disagree' with.

If I tend to insist that young and budding programmers develop their own opinions, it's purely because I have my own shellfish interest in pushing young and budding developers on the path of thick skinned shamelessness and turning them to the idea of having their own opinions and expressing them fearlessly. Ravi Mohan in his blog post explains mistakes most people make by not associating themselves with opinionated folks. He uses words which are much more articulate than mine:

When given the choice of picking between a flock of sheep who agree with everything I say vs. picking opinionated troublemakers who think differently than I do and are willing to discuss, brainstorm and argue, I would pick the opinionated troublemakers any day.

When following people, I would rather follow folks who have their opinions and are willing to discuss, brainstorm and argue with me when my opinions are different than theirs, over folks who expect me to follow orders blindly.

Some of my favorite authors are opinionated. Even some of my favorite books are highly opinionated.

If you think having opinions and expressing them loudly and boldly is a bad thing, the green pastures are waiting for you. Happy grazing.

If you have strong opinions on programming, programming languages, design, user interface, how software aught to be built, or anything to do with programming or the craft of building software, and are unashamed to express them; you've already joined an elite group. Congratulations!

On the other hand, If you have opinions but haven't started expressing your opinions loudly and boldly, may I suggest that you start now! Having your own opinions and expressing them isn't easy; but the effort is worth it. It's better than joining the flock of sheep grazing harmlessly on the safe green pastures day after day.