Sometimes what you want to be is best defined by what you do not want to be.

Success-Factors CEO Lars Dalgaard has a passion for developing a company where employees are nice to each other. This point of course, is described much more articulately by his passionate hatred of ass-holes than it is by his love of niceness in the workplace.

The folks at 37Signals define this as picking a fight. They explain:

They explain why picking a fight helps:

Jeff Atwood refers to this process of picking up a fight as having an arch enemy.

Overall, advice from Jeff and the folks at 37signals is just as relevant to career building and life as it is for product development.

As a part of my day time job, I interview countless young and budding developers around the world. Honestly, even today, after years this excersise, I continue to be amazed by the level of indifference most candidates demonstrate during their interview. They will move from .NET to PHP and Scrum to CMM Level 5 implementations, with no personal preferences what-so-ever, only if you were to hand them the job they seem to need so desperately.

In a world where most programmers can't program, and only a minuscule number of them are capable of forming their own opinion on anything; asking them to feel so passionately about a way of building software, a technology or any idea for that matter; that they start considering it their arch enemy or friend might be too much to ask for them.

On the other hand, if you are reading this blog; chances are high that you do not fall in this category of programmers. Chances are also high that you take your work passionately and consider it more than just a way of earning your lively-hood; and that dear reader, implies that you need to find your arch enemy.

During the early days of my career, I lived the life of a conventional good programmer climbing the ladders of promotion year after year with a passion for programming and a will to learn whatever it takes to get those promotions. Life was both comfortable and highly boring; till the time my first successful failure defined my arch enemy for me. Honestly this project did the job of defining my enemy much more clearly than I would have hoped.

Since then I've passionately hated all forms of stupidity that happens in the name of organized process and corporate culture.

My name is Pops, I write shitty code with bugs and my arch enemies include stupidity, lame conventional management ideas and incompetence camouflaged under jargons, the pretense of so-called 'serious software development' and 'process'.

It is of-course a hugely big enemy to pick; as it turns out, there is more stupidity in the world of software development then there is common sense. Take a quick look; chances are high that you'll find it all around you.

Picking up fights with this mammoth arch enemy has allowed me to bring about small changes in my universe. It has taught me more about being a better software developer, a better manager and above all a better human being. Much better than what I would have ever learned to be had it not involved working passionately at learning how to beat this arch enemy.

As far as the fight is concerned; it is far from over yet.

Have you picked your arch enemy yet dear reader?

Which fights are you fighting? 

If you have no enemies and no wars to fight, you might be missing out on a whole of lot exciting challenges, passionate struggle of thoughts and above all an ability to be 'remarkable'.  

Whether you are building a product, building a career or building a life; having an arch enemy is much more important than most people think. 

Pick a colossal arch enemy and then work passionately to wipe out it's existence from the surface of this planet.

I wish you good luck.

As a project manager, team lead or someone who works with a team what is your biggest nightmare?

When a couple of your smartest developers agree to disagree on something stupid and none of them is willing to give up or let go.

In the interest of keeping this post short, allow me to use my artistic skills to represent the scenario.

At my early days at Multiplitaxion Inc, I saw countless young and budding managers avoid these situations and issues like a plague.

Their excuse --- "I think I will let them sort this out mutually".

The reality --- "Are you mad? I am not sticking my neck into this mess; specially for the salary I get".

A major part of your job as a manager is to differentiate healthy arguments from never ending deadlocks.

You are supposed to spot deadlocks from a ten feet radius and make sure people do not stall and thrash their brains over never ending deadlocks.

You may not have the right answer. No one in your team might have the right answer; but anything close to the right answer is better than nothing.

Situations like these are precisely the kind that will require you to put your foot down and take a stand. This is exactly the kind of thing which requires your involvement, judgment, decision making capabilities, straight forward feedbacks, a strong spine and conviction.

Go ahead, make a call; take a stand. 

Then take responsibility for any failures if you encounter hiccups when your team moves forward based on your judgment.

Show us what you're made up of Mr. Manager.

I dare you.

On a side note, as far as that picture above is concerned -- we're just going to go with five for the time being.

As acquaintance, who for the purposes of this post we shall refer to as Fred, cried on my shoulder about his incompetent team-lead earning more than double his salary; I was pleasantly surprised at the openness of his organization. It seemed like it would have taken a lot for his organization to make him privy to information that most organizations consider confidential - his immediate reporting manager's salary for instance.

From the tone of authority with which he flaunted the facts and figures pertaining to his organization; it sounded like this was one open organization that had no secrets.  It sounded like his organization was built on a very open culture.

His professional world, seemed like it was made up of what can be generally described as 'transparent'.  

It was after around an hour long conversation that I finally figured out that his professional world was in fact, nowhere close to transparent. The facts and figures Fred was flaunting to me were figures picked up from the gossips that flowed through the corridors of his organization. Questions flashed through my mind as I heard Fred complain away to glory. I didn't think about questions aloud but they were pretty much on these lines:

1. How did Fred know if any of this information was accurate?
2. Did his managers even know he had inaccurate information picked out of empty gossips; information that he was using to make judgment calls as important as deciding if he should continue with the organization or look for a different job?
3. Did Fred himself know the true source of the information; and much more importantly; did Fred even care if the information was accurate or not?

This was clearly a case of the a modern day so-called-flat organization that wasn't quite there. An organization that read a few articles about Google, said - "sure, we can be like that" and then went out and missed the whole point.  After listening to Fred for almost an hour, more than I felt sorry for Fred, I felt sorry for his manager and his organization.

What I was witnessing first hand was what can be otherwise described as lack of information resulting in information being 'constructed'.

Jurgen Appelo in his post on Why Great Managers Have No Secrets describes this phenomenon itself, how it works the dangerous of 'constructed information' and how to prevent it, rather articulately:

In the same post, Jurgen gives sound advice to managers wanting to push for an open culture and avoid un-necessary gossip or randomly 'generated' information. He explains:

As managers we love the idea of the team being completely transparent. When something is broken, we want to hear it; when things don't work we want to be involved; when a team member is thinking of quitting we want to be informed so that we can make alternate arrangements.  The problem with transparency however; is that it doesn't work one way.

You can chose between a transparent flat culture and a highly political one; but if you pick transparency the same employees who look at you in the eye and tell you how badly broken their project is; over a cup of coffee; will ask you what your salary is over an informal lunch.

It doesn't stop there. If these guys are smart, besides being open, they will also form their own opinions on how much you should be paid and then make intelligent mental judgments on whether you justify your salary.

Before you go out there and blow your trumpet of transparency; what I intend to do with this post, is to tell you dear reader, that it is perfectly healthy for this to happen in your organization; if you consider it transparent. If you have a kick-ass team of developers; and a huge part of your team cannot justify your salary; you probably don't deserve it.

The short point of the long winded is simple; you can't pick the direction and the exact level of transparency you want to have within an organization. Open transparent culture is something that you need to inject in the DNA of an organization. It is a road on which organizations choose to travel life-long and get better over time.

If you're going to take your first three steps of on the path of transparency and then stop; may I suggest, dear reader, that you do not waste your time trying to being about 'some' level of transparency; because your team will have the fundamental building blocks of 'constructing' information and will make educated guesses leaving you in no better position than the hugely political environment full of random gossip your started off with in the first place.

If however, you are going to go all the way eventually and are willing to walk this path with life-long commitment you just might see the passionate commitments developers have for their jobs, their teams and their workplaces.

Transparency is not something that you can just expect as a manager but not give back. It is not something where you can freeze the exact level of transparency you want. You can't have some of it and then stop; because if you do than what you are basically left with is a culture that's not transparent; a culture where constructed information and random rumors are given room to flourish.

Put simply, transparency comes at a price and is often rather expensive. It is a commitment; a way not life; not just a buzz word you put on your website. 

If you've taken your first steps towards walking the life-long path of transparency; but are not quite there yet; all you have to do is keep nudging yourself and your team to get a little more transparent each day; each year. Very soon you'll see a level of maturity from your employees that you never even dreamt of. I wish you good luck.

If you're not walking down the transparency path; I wish you good luck anyway. You're going to need it. Lots of it.  

Go to your organization's website; How many of these words can you find there: ROI, Quality, Scalability, Security, Reliability, Extendibility, Enterprise. How many other hollow words lacking meaning, purpose and any form of originality can you find on your website or your corporate blog? If you can count more than ten occurrences of those words, here's my ten-to-fifteen-year-prediction for your organization.

Obviously, it won't happen overnight; but it'll happen.

That or your organization will forever remain in the realm of mediocrity; much like the Taxi cabs waiting outside the airport; all of them looking exactly the like other; competing for the same set of customers and landing on their customers by random co-incidences.

Guy Kawasaki in his book The Art of Start gives advice to young and budding startups on how to differentiate themselves. He explains:

Much like the crappy jargon guys; organizations that use these words are flaunting the fact that they know nothing about making these words a part of their life-style. It's an open invitation to any mind with two brain cells or an iota of common sense to land on these websites and call the bluff.

Putting words like quality, ROI, security, salability, enterprise on your corporate website while describing what your your organization does; is like introducing yourself to a stranger who you meet for the first time, with one of the the following lines:

1. Hi; I am Fred and I am clean. I have a bath every day.
2. Hi; I am Fred and I wash my hands after when I leave the toilet.
3. Hi; I am Fred and I wear clothes to office.

I could go on forever, but you get the idea. Making a big noise about Quality, Scalability, Reliability is like considering your having a bath every day your core strength.

It's stupid. Insanely stupid.

On the other hand; look around and you'll notice quite a few organizations using these words rather generously. Reasons; as stupid as they may be; are rather obvious. If you find more than ten noise words on your corporate website or product description it's probably because of one or more of the following reasons:

1. Your organization has little or no respect for users. Most software companies tend to think their customers are idiots anyways.
2. Your organization is busy playing it safe and actually enjoy being the white cows instead of working to become a purple one.
3. Whoever owns the content for your website is either way too conventional; or just doesn't get it. 

All you do by using these words on your corporate website, is flaunt that you have a marketing team that thinks your customers are idiots. That or the fact, that your organization knows nothing about these words; because those who do; make it a part of their life; just like they have a shower every day. These individuals and organizations alike; do not make a big noise about it.

Hollow random big words on your public website end up being nothing other than an advertisement of your organizational ignorance and immaturity.

Avoid random marketing words that lack any clarity, meaning or originality on your website and while speaking to your customers.

If you happen to have random hollow words on your product website them consider removing them.

Long story short, don't create product descriptions and websites that are, as Guy Kawasaki articulately puts it --- impotent.

Don't bastardize your content; whether it is for your public website or your blog.

Give your website content and your product descriptions an impotency check today.

Tell us something different.

Tell us your superpower.

We won't mind if you're crappy; talk about what is it that makes you 'remarkable'.

Tell us why we should care.

Seriously.

There is a certain sense of pride and joy you can get out of having an idea that will not let you go till to work on bringing it into existence. Then you work on shaping it into form; turning it into something concrete; in the form of an application, a website, content or what-ever-it-is that you work on; that can be shared with the rest of the world. It is much like the act of giving shape and figure to raw sand, shaping a mud vase or drawing on a blank canvas.

As a perfectionist; you enjoy the art; and you want to give whatever-it-is-that-you-are-working on the final touch of a specialist before you show it to anyone.

If you have been a part of any product team and have gone through a few releases, chances are high that you have been a part of release meetings where even the most kick-ass developers are arguing and trying their best to delay the release of the product. They feel they need more time for finding and ironing out every little bug that exists in the system. I wrote about this in one of my earlier post.

This is where most start-up companies, young budding programmers, big software shops and even the so-called-veterans of software development tend to go wrong. If the fundamental premise on which your product is built, is remarkable, your audience really doesn't care if the first version of the product is --- crappy.

Guy Kawasaki explains how to address the dilemma of when-to-ship in his book, The Art Of Start:

Guy literally refers to this as the 'Don't Worry; Be Crappy' rule in his live presentation when talking about his Macintosh evangelism days:

Dave Winer, in his blog, takes pride in building software that is made up of shitty code with bugs. He explains:

It is easy to knit your brows at Guy's thought process and Dave's thought process on this topic; but if you give a little bit of time and effort to read between the lines when you read Dave's post or the Art of Start; you realize that what Dave and Guy are taking pride in, is not the shitty-ness of their code, crappiness of their product or the fact that their application and products have bugs.

They are in fact taking pride in the fact that they worked on applications and products which were built on a beautiful idea capable of defending itself, which were brought to existence.

That and the post is a subtle reflection of the sheer human stubbornness to keep showing up, sticking to it and make things better with time. 

You really don't need to worry about how crappy your application is before showing it off to the rest of the world. What you need to worry about is the basic premise of thought on which the application is built. What you really need to worry about is - Will that thought endure the test of time and keep you involved even after the big-bang-hype of your release dies.

Everything else; is secondary.

For almost a year, this blog suffered from starvation of content because of my desire to meticulously spell-check and grammar check every post; polish each picture; constantly question if the post met the quality of something that can be published. Once in a while; people were kind enough to give me gentle nudges and tell me that I need to write more often; and I agreed; but I hardly ever reacted by taking corrective action.

Then something happened. It wasn't a Hollywood-type-flash-of-light-realization, but it was fairly close.

I realized that it was okay to have a couple of typos here and there; as long as the premise on which the posts were built had the potential to make a small dent in my world and yours, dear reader.  I realized that I could come back anytime and fix the typos; which I often do. As a matter of fact, I continue to scan my own posts for typos even after publishing them.

I had similar realizations with striking similarities even in the world of shipping working software.

If there is one thing you take away from this post it is this: Don't waste time chasing the desire of getting it right the first time. If there is something you want to chase, chase the sheer human stubbornness of continuing to show up. Everything else is secondary.

Whether it is your new product, blog or your life; Guy's advice holds true.

Don't Worry. Be Crappy.

I wish you good luck.

I spend countless hours out of my job life trying to interview managers who try to draw strict boundaries between personal and professional life. 'Don't take it personally', seems to be the management advice we seem to be giving our young and budding managers, as if it were some management mantra of success we are whispering down down their ears.

We train them to become oblivion to what can happen over a cup of coffee or a glass of beer; where else what we should be teaching them is The Godfather. 

If there is one thing I've learnt after years of working with small, yet closely knit teams of kick-ass developers, it is a lesson The Godfather inscribes rather clearly and articulately --- "In business, everything is personal".

In his book, The Art of Start, Guy Kawasaki, advices young and budding entrepreneurs to 'make it personal' when pitching their idea to venture capitalists:

For someone who told you dear reader, why no-one cares about you, your product or your blog, asking  you to add 'personal touch' to your work life might sound contradicting; but it isn't. It is the very fact of how the craft of building awesome software happens around the globe. The personal touch with each other, is, as a matter of fact, the secret sauce of hugely successful teams. An innocently unplanned team dinner is often the best project management tool ever.

Investors worth their salt knew the importance of personal touch even in a field as detail oriented, based on facts and numbers as financial investment. Steve Yegge  describes the warren buffet rule of investment in his rather long winded post on requirements.

The rest of Steve's post of-course is irrelevant to the context of this post, but what strikes me most, is Steve's description investors like Warren Buffet and how importance they give to the 'personal element' while deciding their investments:

Snap back to the world of software development. Diving into the depths of time, back in the days of Multiplitaxion Inc, I witnessed a senior manager being accused of granting a junior developer high ratings on his appraisal because he had better personal touch with the individual. This senior manager spent a decent amount of time trying to defend himself and ended up proving how the individual was way more efficient than others in question.

As I watched the incident unfold, I worked hard to figure what was so grossly evil about giving someone a high rating because he had a strong personal relationship. A strong relationship that had resulted out of mutual respect for each other's competency. A relationship formed out of working closely together during; and even after work hours. What was so wrong with honoring a strong comradeship based on mutual respect for each others quality of work.

During my course of software development, I've seen people lose their jobs for personal reasons, people get promotions for personal reasons and projects getting stalled because of relationships gone sour with clients because of personal reasons. I have been a personal witness to a rather crappy code base getting accepted because the client liked us, during the early part of my life as a developer. That's how powerful personal things are; even in professional life. 

You can sit here, bitch, moan and cry about how all of that is unfair; or you can embrace the fact and connect to your customer, clients and readers on a personal level; because if you do, they will reciprocate; and that, dear reader, will be a genuine relationship.

A relationship where you will earn, not just a customer, a client or a reader, but an honest well-wisher, who, in the long run, will care; not about you; but about whatever-it-is-that you have to offer them and the value it adds to their life.

In the world of software, much like pretty much everywhere else, everything is personal and if you don't get that, I'm going to have to call you an blooming-idiot and assume you don't take it 'personally'.

On a serious note, realizing how small personal touches and relationships have large impact on everything, is a crucial first step to understand software development in general and project management in particular. Connect with your team, your clients and your readers at a personal level; after all;  when it comes to business or your professional life, everything is in fact personal.

Crux was developed at work; but as far as act of writing code was concerned, it was basically me; as the only human being; slamming away at the keyboard during the middle of the nights to deliver a project which would help one of our customers track their inventory as it moved across various departments. The code that went in the codebase and eventually in the base framework followed one simple thought process. This post is about that approach or way-of-life.

As a trickle of few downloads happen on the CodePlex SVN and as a small team of rather talented programmers starts looking at it; some interesting ideas have started emerging. Every time however, an idea for a new massive feature is thrown in, over a casual discussion, I tend to take on a rather defensive stance.

It is not because I doubt the team's ability to shape the idea into reality.

It is merely because --- I hate code.

For someone who loves programming enough to write romantic poetry on it, the claim of hating the idea of writing code, sounds like a joke; even to myself; as I write this; but it is, as a matter of fact, true.

There are cases where I hate the idea of writing code; from the core of my heart; particularly when the idea of writing a class, a function or a page cannot catch me by my collar and convince me that it needs to turned into reality that exists in the form of a framework or application feature.

For months, I considered it something that was under the YAGNI label and felt rather passionately about it or synonymous to making-each-feature-work-hard-before-you-implement-it thought process; but it is in fact more than that. It is indeed a way of life described rather well by Richard Bach in the Foreword of his book Illusions - The Adventures of a Reluctant Messiah. Richard explains:

At the first sound of it, the idea might sound like a poetic exaggeration; but the approach has, in its own subtle way, become an integral part of my thought process. If an idea doesn't haunt me enough it doesn't get translated into C#.

If a thought doesn't haunt me enough, it doesn't get translated into a blog post and doesn't show up here. 

Whether you are a developer, a designer, a writer or whatever-it-is-that-you are; develop a love-hate relationship with your ideas. Entertain thoughts without accepting them; give them room and environment to flourish or grow but when it comes to nurturing them or standing behind them pick the ones which are strong enough to catch you by your collar and not let you go till the time you take them up.

If you have to convince yourself consciously about the strength or effectiveness of an idea, it is not good enough to bring you happiness and satisfaction in the long run. Next time you get an idea that needs to turn into code, a blog-post or take any other form of existence; try ignoring it; and see if it gets strong enough to strike back and remind you of its need to exist.

If it does, you'll begin to genuinely love and enjoy the process of seeing it come into existence.

If it doesn't, it was just a distraction or just something that wasn't worth wasting time on.

If you're associated with software development and you haven't seen the movie office space you should. The particular scene in the movie to watch out for is the one where Tom Smykowski, the business analyst is questioned about his role and what it is that he does in the organization.

If you are content with a low-resolution version of the scene just so that you can get the reference-to-the-context of this post and follow along, there is a rather ugly version here. Having pointed you to that, I highly recommend, renting a DVD and enjoying it in the comfort of your couch.

The question the business analyst was asked in the scene might sound hilariously funny; but is, in reality, a rather profound question every business analyst out there should be made to answer:

What would you say you do here?

Ask this question to a truck load of business analysts around the world and I'm sure you'll get similar versions of the answer, that you heard in the movie. That and you'll get a truck load of similar crap about:

1. Developers not being good at communicating with the client.
2. Developers not being good enough to understand the business domain and the problem.
3. Developers not being expressive or articulate enough.

For the truck load of answers I tend to get, I usually have one standard reply that fits them all: Bullshit.

At Multiplitaxion Inc, projects with one or more dedicated business analysts who did nothing else, had a notorious history and reputation of failing miserably. Somehow our resource management group leaned towards believing that having a dedicated business analyst associated to a project has nothing to do with it's success or failure.

The resource management group, of any organization, however, is not exactly the kind of people expected to be following up project management, software development, or for that matter, how the craft of software development is evolving over time. Put simply there are not the group of people expected to be following up on process mavens like Scott W. Ambler or questioning the very existence of the role of a business analyst. Scott in his rather elaborate and pragmatic article explains:

The article is full of warnings, which are not just based on personal opinions or random theory; but based on real life experience instead; quite a bit of which I've personally been a witness during my years of association with software development. Scott explains:

It is a rather long-winded, pragmatic and objective article, not just interested in nailing the role of the business analyst, but trying to understand pragmatically where a role of that sort fits in the larger scheme of things. It is an article every person, responsible for making hiring decisions, in any organization that wants to do anything meaningful other than what a typical body shop out there does, should read.

I've never been against the idea of doing analysis; but working under the assumption that people who are capable of building the entire system, testing it and taking it to a production ready state are incapable of understanding what it is that they need to build sounds a little over-the-top and absolutely stupid.

Every time I get into a discussion with folks who are still into Big Design Upfront approaches of software development or people who draw their inspirations out of Indian body shops, that sell bodies, pull frauds and offer no meaning to the larger scheme of things; the importance of the role of a dedicated business analyst just keeps coming up all the time.

If you are trying to run a project with programmers who are fundamentally incompetent, have no talent or desire to communicate and if your selection criteria of programmers is based on principals formed during the cheap outsourcing era, throwing a business analyst in the equation will not set things right. If you have a kick-ass team of one man armies, removing a business analyst from the equation will hardly make any difference.

Some of the best business analysts that I have met and worked with, have been people from the development or testing team. They  are people who rise to the occasion of doing analysis when required and then get back to participating in the development or testing once the analysis is done; rising up to the occasion every time it is needed in the course of the project.

Long story short, most kick-ass business analysts that I've worked with have been development leads, QA leads or project managers, who have coupled up as a business analyst. So much so that I've started believing that you 'find' a business analysts in teams of kick-ass individuals. You don't hire one.

I'm sure I'll have quite a few knitting your brows as you read this; quite a few of you, dear reader, are already thinking of telling me about that ninety page requirement document that the developers cannot prepare is really important; or you are flexing your management mussel and thinking about telling me telling me how developers are not good with UML.

You know what --- don't even bother.

I've been there and done that.  The documentation that you are thinking about, if you are thinking about one, is nothing more than CYA.

During the early part of my career, my role was to reverse engineer 'use cases' and UML models out of C++ code base which had been written by a team for literally more than fifty lousy individuals who had been outsourced purely for cost reasons.

If there is one conclusion that I came too, after brining some sense, into that specific project; collectively screwed by fifty developers and a very senior business analyst; it was this: CMM, other process or UML will not result in a successful project. Hiring a kick-ass team of competent individuals will.

Besides, Stewart Armstrong in his article where he questions if we should shoot the business analysts, seems to suggest that, eighty percent of the errors which cause projects to fail happen at the so-called requirement-gathering stage.

Analyze That!

Now, go ahead; get a full time Business Analyst for your project if you must, but before you do; ask him the million dollar question:

"What would you say you do here?"

If he is able to give you a convincing answer; by all means, hire him; but if he can't; and gives you the I-can-help-you-understand-the-requirements-because-your-developers-can't-or-I-can-help-you-draw-up-your-specifications-because-your-developers-cant crap consider not hiring him.

If you do end up hiring him, chances are high that you're not just wasting your money; you are, as a matter of fact, risking your project by introducing an additional monkey that'll have to be subdued and sedated as your project moves on and the rest of your team starts doing some real work.