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:

Most companies use the same terms to describe their product or service. It's as if they all believe that their prospective customers have been living on a desert island and have never before heard a product or service referred to as "high-quality," "robust," "easy-to-use," "fast," or "safe." To see what I mean, apply the Opposite Test: Do you describe your offering in a way that is opposite to that of your competition? If you do, then you're saying something different. If you don't, then  your descriptions are impotent.

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:

A You can spend hours discussing these questions with your team. It won' t be easy to reach a conclusion, and there is no "right" or "wrong" answer. Another way you can approach this dilemma is to ask yourself, Would I let my mother or father use the product or service in its current state? If the answer is yes, ship it.

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

So, Don't worry be crappy - the concept there is, if you wait for the perfect world; if we had waited for chips to be cheap enough, CPUs to be fast enough, color display, Ethernet port, slots; if we had waited for everything to be ready for Macintosh, we would have never shipped. We would have 'never' shipped; and so, as long as you are truly making meaning; if you've leaped curves; if you have a revolution; I think the market will accept elements of crapiness to a revolution. I am not saying ship crap. I am saying ship something that is revolutionary with elements of crapiness to it. Very, Very different; and I truly do believe that in high tech the way it works is that you ship and then you test. Other than life sciences; you ship and then you test.

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

An old software slogan at Living Videotext: "We Make Shitty Software... With Bugs!" It makes me laugh! We never ran this slogan in an ad. People wouldn't understand. But it's the truth. We make shitty software. And so do you! Software is a process, it's never finished, it's always evolving. That's its nature. We know our software sucks. But it's shipping! Next time we'll do better, but even then it will be shitty. The only software that's perfect is one you're dreaming about. Real software crashes, loses data, is hard to learn and hard to use. But it's a process. We'll make it less shitty. Just watch!

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:

I recently met an entrepreneur who wanted to start an online service to enable people to create trusts for their pets. She was concerned that sometimes people died before their animals. Her pitch hinged on the fact that nine million pets are euthanized every year in the United States. My first reaction, as a venture capitalist, was that nine million pets may get euthanized, but not all of them because their owners died. Few are probably euthanized for this reason, so the market isn't as big as she thinks. My second reaction, as a dog owner (Rocky Kawasaki, boxer), was that she was right: What will happen to Rocky? He wasn't included in any of my family's wills and trusts. The lesson is this: Position your product or service in the most personal way that you can. "What happens to Rocky?" is much more powerful than "What happens to the nine million pets?" If you hook  me with a personal concern about my own dog, I can extrapolate this to the millions of other people who are concerned about their pets.

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:

Let's say, for instance, that you hear that Subway (the sandwich franchise) is going to do an IPO. They've been privately held all these years and now they're going public. Should you invest? Well, let's see... the decision now isn't quite as cut-and-dried as it was in their rapid-expansion phase, so, um, let me see, with current economic conditions, I expect their sales to, uh... let me see if I can find their earnings statement and maybe some analyst reports... No! No, No, NO!!! Bad investor! That's the kind of thinking that loses your money. The only question you should be asking yourself is: how many Subway sandwiches have I eaten in the past six months? If the number is nontrivial — say, at least six of them — and the rate of sandwiches per month that you eat is either constant or increasing, then you can think about looking at their financials. If you don't eat their sandwiches, then you'd better have a LOT of friends who eat them every day, or you're breaking the cardinal rule of Buffett and Lynch.

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:

I do not enjoy writing at all. If I can turn my back on an idea, out there in the dark, if I can avoid opening the door to it, I won’t even reach for a pencil. But once in a while there’s a great dynamite-burst of flying  glass and brick and splinters through the front wall and somebody stalks over the rubble, seizes me  by the throat and gently says, “I will not let you go until you set me, in words, on paper.” That’s how I met Illusions.

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:

You definitely need to do analysis, but whether you need someone who just does that is a really big assumption.  Agile developers are generalizing specialists, people with one or more specialties, a general understanding of the software process, and a knowledge of the domain.  One of their specialties might be in analysis, or then again it might not.  It is unreasonable to expect everyone to be an expert at every aspect of software development, but it is reasonable to expect IT professionals to have some analysis skills and for some people to have deep skill in this activity (amongst many of their skills). You need to do analysis, but that doesn't imply that you need analysts.

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:

A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills. Remember, BA is also the abbreviation for band-aid.

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.

If there is external factor that I've seen destroy organizations and careers, preventing, whether it is individuals or teams, from doing things which are remarkable and having fun, it is --- distraction.

Paul Graham, in his list of thirteen things that he wants to tell each startup warns startups against distractions:

Nothing kills startups like distractions. The worst type are those that pay money: day jobs, consulting, profitable side-projects. The startup may have more long-term potential, but you'll always interrupt working on it to answer calls from people paying you now. Paradoxically, fundraising is this type of distraction, so try to minimize that too.

With 'business propositions' from three different individuals and three rather tempting job offers in last year alone, for someone like me, who isn't even looking for business propositions or random job offers, distraction definitely seems to be one of those things that is not that easy to avoid. Paul Graham, while talking about disconnecting distraction, explains this much more articulately that I will be able to explain it:

Procrastination feeds on distractions. Most people find it uncomfortable just to sit and do nothing; you avoid work by doing something else. So one way to beat procrastination is to starve it of distractions. But that's not as straightforward as it sounds, because there are people working hard to distract you. Distraction is not a static obstacle that you avoid like you might avoid a rock in the road. Distraction seeks you out. Chesterfield described dirt as matter out of place. Distracting is, similarly, desirable at the wrong time. And technology is continually being refined to produce more and more desirable things. Which means that as we learn to avoid one class of distractions, new ones constantly appear, like drug-resistant bacteria.

But distraction isn't just about technology. Distraction has an uncanny ability to morph into multiple forms and disguise itself before it strikes you and your rather fun filled life which is moving in one direction. If you are a programmer or involved with the craft of building software, this post, dear reader, is my humble attempt to present to you multiple forms of distractions which might be working on keeping you from doing things which are 'remarkable'.

May I suggest, dear reader, to use this list as a reality check of just how many distractions you have in your work life and decide for yourself if those distractions might be preventing you from coming out with results that make small dents in a large universe.

Distraction #1 - Television And Technology.

Seriously. There are dedicated posts and entire sites dedicated on this topic and how big a distraction these are. Television, video games and random social networking websites are the single largest distraction to programmers that I've ever seen. Wasting countless hours writing on the scrap book of your class two friend, now barely an acquaintance, might be a really healthy way to pass your time but does not get anything done in the long run.

If you've seen your Yahoo messenger and email notifications popup as you try to focus on getting some real work done, you probably do know exactly what I mean.

Television and technology that is addictive and disturbing is nothing more than a random distraction.

Distraction #2 - Job Offers And Business Ideas.

Last year alone, I was given three fairly tempting job offers without even applying. More than three groups of people, including a medical teacher, wanted me to hear him out, listen to his business proposition and give 'due thought' and consideration to his business idea.

Considering job offers, listening out business ideas and giving them 'due thought' is mentally stressful and distracting, particularly when you are settled and moving in one direction where your life seems to be taking you naturally.

Unless you have genuine problems with your work-life, try to find a second home, away from home and settle down. Then gear up for some real work. This stuff is supposed to be fun; and every job change demands you spend another six months to a year, to get people around you; get people to respect you and get people give a rat's ass about what you think or have to say.

In any organization, irrespective of how awesome or kick-ass it is, it takes time to create room for yourself, get people to listen to you, give you freedom and trust to maneuver. Earning this trust and room to maneuver is a 'means' towards products and outcomes which are remarkable; it's not an end.

If you've been lucky enough to have found an organization that gives you trust and room to maneuver; stay put and utilize your time to create long term win-win situations for your own career and your organization. Jumping from one job to another in these cases, is nothing more than random distraction.  

Distraction #3 - Travel And Changing Cities.

When you begin you career as a young and budding consultant, travel seems like fun. You get to see new places; meet new people and learn from different cultures. After you've done a decent amount of learning that is necessary for your life; travel quickly becomes a major distraction. Hotel suites and plane flights are not the best places to give focused effort towards what you love working on.

With a home and family, you build a support system so that you can focus on doing whatever-it-is-that-you-love doing. Constant travel takes that support system away faster than most consultants think.

Settle down. Focus. Work. Avoid travel. Do it only if you 'have to'. Travel, is nothing more than a random distraction.

Distraction #4 - Taking 'Help' A Little Too Far.

If the can-you-help-me-fix-my-machine-this-weekend questions sound way too familiar to you, you might be vulnerable to distractions. There's nothing wrong with helping as long as you can draw your lines and know when to stop.

A couple of months ago, for example, I received a call from an acquaintance who hadn't called me in the past three years. Thing gentleman wanted me to help him with his inventory control only to find out later that he was expecting me to design and build an entire freaking system for him under the banner of 'help'.

As much as you would like to be nice to everyone, especially, your child-hood friends and acquaintances, it is a sorry fact of life that the kind of people who make you feel like wearing that no-I-will-not-fix-your-computer t-shirt all the time, do exist on the same planet as we do.

There is nothing, I repeat, nothing wrong with going out of your way to help others; but knowing when the expectation of 'help' is being stretched a little too far and knowing when to stop is equally important.

Help, taken a little too far is nothing more than a random distraction.

Distraction #5 - Hot Technologies Out There.

Everyone has a product which will change the world and every product out there fits your need and your requirement; but that doesn't mean you need to care.

Yes, cloud computing might be the hottest freaking technology out there, but for your own sake, figure out how much relevance it has in your life, your organizations life before you start spending countless number of hours on it.

Not to single out just cloud computing, we spent some amount of time doing a small project in Windows Workflow Foundation; the next time on when we needed simple long running workflows, we just built a small XML based workflow engine to give us everything we need.

Just because a technology is 'hot' and it's 'out there' the experts, for obvious reasons, will exert some amount of pressure on you and make to believe you really 'need to' spend time on learning it. Time spent learning tools and technologies that have no relevance in your life, what so ever, at the cost of being mediocre at your core competencies, can be devastating for your career in the long term.

Resume Driven Development is harmful; not just for your organization but even your own career. It is in fact, nothing more than a random distraction.

Distraction #6 - Generalization Taken Too Far.

This might sound paradoxical to my advice of becoming a one man army but it's not. Turning yourself into a 'generalizing specialist' is good; but not knowing when to stop and forgetting what your core competence; in order to achieve generalization is stupidity.

When you are consulting; and you have Oracle certifications, your continuing with Oracle projects, especially when they are billed at a higher rate, might make much more sense to your organization than it might make sense to you. After I did my Oracle certifications and one small project on Oracle I had to pull the plug and detach myself from Oracle Development and database administration.

For me, understanding how the oracle architecture works was a way of improving my design skills; not a career change. I had fun learning; but it was 'not' what I wanted to spend the rest of my life doing. The same of-course, in my case, also holds true for system administration, my MCSE certification and the one year part-time system administration that I did.

Being a one man army is good; but know what you love doing; and when it's time; pull the freaking plug and stop doing things which are not equally important in your life. Be a generalizing Specialist, not a multi-purpose tool.

Generalization taken too far is nothing more than a random distraction.

Distraction #7 - Meetings And Committees.

Meetings are heroin of the software development world and committees aren't just lame - they are dangerous.  I've personally been drawn in the meeting-culture once, only to realize how much time and energy it can take away out of you without even making you realize that. When you are in a meeting, you are not productive. Meetings and committees are distractions of the highest order, particularly when it comes to software development and your career.

Each one of these, deserve a post by themselves, but this is not a post about these specific distractions.

The list is, indicative but not exhaustive.

Some of you, dear reader, may not even recognize these distractions as things that might be doing you a disservice. They may be intertwined with your life, but remember, if you are indulging in them they 'are' consuming more time and energy from your life and preventing you from doing what you really love doing. They might be wasting much time out of your life than you think.

Take the Steve Jobs approach to life and figure out the things that you would do if you were going to die tomorrow.

Everything else is a distraction; treat it as such and give it as little time and energy out of your life as necessary; leaving you with room, time and energy for what you truly love doing. Avoid time and energy drains.Then go out there and do what you truly love doing. I wish you good luck.

Living by my philosophy of putting myself dangerously close to getting fired; sometime late last year; I ended up taking the task of working as a single programmer on a product which had been estimated to require five programmers.

Put simply, it was an 'inventory tracking system' for one of our clients involving complex workflows. Besides having client specific requirements the part of the product that we at eFORCE owned consisted of modules which could serve as building blocks for quite a few other typical web applications.

Because it consisted of the fundamental building blocks that any web application might need, we decided to call it Crux.

When we had implemented the project using the core of the product, ended we played around with the idea of open sourcing the code base of  the base framework. We did this primarily because we believed that what we had; might be able to help other developers and organizations around the world get jump started with their web-application. 

If you've worked in a typical software development shop and have ever tried to get a piece of code for one of their products,  you are working on, to be open-sourced, because you believe it will 'help the world', you probably know the reaction. It's like dropping a dead rat on the conference table in the meeting room.

Your managers and executives will probably look at you like you're an alien with a third eye when you utter the words - 'open source' and the product name that you built for them in the same sentence.

That is exactly where working in an organization that's not a 'typical software development shop' and genuinely values in innovation and collaboration helps.

When we started talking about open sourcing Crux, I was pleasantly surprised at the level of support and understanding I received from everyone whose approval I needed to get this thing out to you, dear reader.

We got this thing open-sourced, froze on the New BSD license which gives you complete freedom to use the code for commercial purposes without any restrictions. We got our very talented graphic designer to work on the skin for the open source version. We had a couple of rounds of code review done by a couple of fellow programmers and were able to get a build rolled out to you, dear reader, in virtually no time with zero meetings and zero committees. 

We've just finished publishing Crux on CodePlex. It's a fully functional release ready sprint but we're going to start by calling it Pre-Beta; primarily because we would like to take some more feedback from you, dear reader. During this time we would like to have room to maneuver for relatively major changes to the database and the code-base if needed.

Crux by it's very nature is composed of multiple pieces which allows you to jump start with your Web-application using it as a foundation. Alternately, you can take individual modules or DLLs out of the Crux implementation and decide to use them individually. This post describes some of those components. Going ahead I will be working on more posts and videos on each of these individual components.

A multi-tenant authentication piece

Crux authentication, unlike ASP.NET membership supports multi-tenancy and allows drawing boundaries between multiple companies which can be hosted and authentication by the same instance of the application. 

A light weight workflow engine

Windows Workflow Foundation is great; and I've myself used it in areas requiring some complex workflows; having said that, I think it's not for a typical simple web application needing basic long running workflows with human intervention. We needed something really light weight which allows us to do simple configurable long running workflows which require human intervention e.g. approval or rejection at every step, very easily without going to a huge learning curve.

Other Pieces A Typical Web Application Needs

We have a Model View Presenter Implementation, a centralized logging piece, a centralized exception handling piece etc. These are pieces we believe all good web applications should have.

We also have a fully functional administration module with a user interface which allows you to create users, assign users to companies, departments, roles etc. Things we believe most web applications end up building with or without membership controls.

Extending the behavior or injecting different behaviors into this administration piece depending on your needs and requirements is also fairly simple. 

Going forward I will be doing a series of posts on how you can use Crux to jump start your projects and applications and we at eFORCE will also be coming out with its official website soon.

I'm also planning on using Crux as a base code base for my code related posts in future so that I can learn how to code better and share my experiences with you dear reader, using an alive codebase rather than lame examples. This blog now has a separate category for Crux related posts which you might want to follow if you are interested in the development of this framework.

The Technology Stack

Crux is built using .NET 3.5, LINQ to SQL and SQL Server 2005 or SQL Express 2005.

Ways To Participate

If you're going to be working on a typical ASP.NET web application that requires multi-tenancy, building an administration piece and involve simple manual workflows I suggest giving Crux a quick test-drive before you start hand-coding these pieces yourself.

We at eFORCE, are also working on getting a team of very talented programmers and one graphic designer, to work on this project during their free time so that you can continue to get upgrades and more features in future.

Feel free to download the code from the CodePlex-svn, play around with it and if you come across bugs, feel free to file them on the project issue tracker. Feel free to file in feature requests, any problems you might be facing with the code base on the project issue tracker as well.

Feel free to email me if you would like to participate or contribute in Crux development and make a very small dent in an unimaginably big universe.

Special thanks to the following folks in the Crux team, in no particular order, for their time, efforts and contributions: Anshuman Srivastava, Esha Patra and Amit Ghosh. Thanks to Sujith Nair and everyone else at eFORCE who has been a part of  the open sourcing decision for Crux. 

More applications, tools and frameworks to come out soon.

Stay tuned for more open source goodness.

What is worse than a meeting where everyone sleeps while the meeting-man talks?

A meeting where everyone has a different opinion, everyone talks and everyone is busy being nice to one another.

If that picture from Don't Make Me Think by Steve Krug looked familiar when you glanced through it, and it felt like deja-vu; it is probably because that is exactly how a lot of critical user interface, software development and sometime even organizational decisions are taken in a lot of places.

During a recent conversation with an individual, while talking about his company, he ended up describing the whole idea; co-incidentally; but much more articulately than I might have explained it myself. I might not be remember the discussion to the minute detail of every thing that was said to be able to quote it word for word, but here is how it pretty much went:

Individual: You know, in general I have nothing against my company; we are all amazing individuals working really hard and doing all we can do to get the right thing done or the right decisions taken; but every time it looks like something is going to work out really well, we work hard; collectively; as a group, to screw things up real bad. Me: Interesting. Am I allowed to use that sentence on my blog? Individual: Sure. Why? Me: It's an interesting sentence. You might read this sentence again on my blog; sometime soon. Seriously. Individual: Sure. Go ahead. Use it.

The whole a-group-of-really-nice-people sitting in meeting rooms and screwing things up seems to be a recurring theme that happens to manifest itself again and again, so many times that you start to question, if there is something fundamentally wrong in the idea of getting things done by perfect consensus.

Turns out, that there are times in software development when 'Committee Driven Development' as we shall call it, starting today, is down right in-effective. Scott Berkun in his presentation on how progress happens describes how democracy is bad in software development:

Committees by definition prevent change. The whole idea is to try and get consensus and consensus will always lead towards mediocrity because you are averaging out decision making. So one of the most interesting stories to me about Rome; this is a picture of the emperor Constantine. [picture of Constantine on a projector] He was a later emperor and one of his claims to fame... if you remember the early history of the Christians in Rome; they didn't like the Christians so much; like the whole 'throw them in the lines thing'… that is not a story; that was true. There are catalogs of all the things they would do with Christians and Jews and slaves and other things. There were hundreds of years of horrible treatment for Christians; and then one day Constantine decided - 'You know what? We should be nice to Christians'. Boom! Edict of Milan, believe it was called. Edict of Milan. And now, next day, everyone's nice to Christians. Boom! Like that. That could never ever, ever, ever happen in a democracy; ever. It's designed to prevent that from happening. But if you're talking about change and I'm not really trying to get into a debate about political structures and tyranny and what not but if you are talking about change; autocracy and solidified centralized power is actually a much more effective way to make immediate change happen.

This opinion from Scott  might be subject to a lot of criticism, by people who are firm believers of democracy, but anyone who has been in a meeting where a bunch of people, having equal or similar power, just cannot get to agree on anything, knows exactly what Scott is talking about.

'Power' by it's very nature is something that sounds like a thing the micro-managers crave and the ones who are into the modern-management, shun; but power itself, is neither good nor bad. In the ideal world power is supposed to be just a quality which enables you to get things done. That's what we mean when we say - you're-being-empowered-to-do-this - It is invariably handing power in the hands of people who crave for it the most, that results in disastrous situations. 

Where most organizations tend to miss out on, is finding the right Constantines who are capable and will indulge in using this power to bring about meaningful change. Quite a few organizations often fail at trusting these Constantines after they have been found, simply because they lack trust. Trust, is indeed, a difficult thing to give to your employees after all. 

People in favor of democratized software development often tend to cite open source projects as an example of development by mutual agreement and consensus; but anyone who has been associated with open source for more than a day knows how the function of a gate-keeper and how important it is to the success of any open source project.

Recent discussions around GNOME user interface that a small team changed, without the community consensus, and then presented these changes back to the community, forms an interesting read. The explain their stand while presenting the final changed to the community:

Although the changes aren't nearly as radical as the original mockups, they are a big change from the current GNOME panel menu. If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design ("you can't make the panel menu depend on beagle!!!") and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. So we did it ourselves, and now either GNOME will like what we did, in which case, yay, free code for GNOME, or GNOME won't like what we did, in which case, no harm no foul for GNOME, and yay, brand differentiation for Novell. (And anyone who yells "fork" deserves to get one stuck in them.) An equivalent answer to the question is "because you can't do design by committee". Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be.  This is just another aspect of the UI "simplicity" thing. We like UIs that try to do the right thing (metacity, epiphany/Firefox, evince) rather than UIs that try to make every possible user happy (enlightenment, mozilla, gpdf/acroread). If you try to design something by committee, you either have to end up with the latter sort of messy does-everything UI, or you ignore and hence piss off a large chunk of the committee.

In the same discussion, the developers submitting their changes, thrash the whole design-by-committee approach rather ruthlessly and end up with a conclusion the individual I quoted at the start of this post had landed up with. The developers who made changes to the Gnome user interface without community consensus explain:

But some people will still say "But couldn't you have discussed it with the community before doing it?" No, we couldn't. If we had, it would either not have happened, or it would have sucked. It's inevitable. It's not a problem with he GNOME community, it's a problem with communities in general. The wisdom of crowds [4] only works in situations where there are clear right and wrong answers. If you try to apply it to a design problem, where there are many entirely different right answers, then you end up with a wrong answer. Always [5]. So to sum up: design by committee is bad, endless debates that result in code not actually being written are bad, design by very small teams is good, software with a unified vision is good, trying out cool new UI ideas is good, free code at least doesn't suck, and of course, for Novell, not shipping NLD10 is bad. I don't think there's anything we could have done to get more of the good without also getting more of the bad.

From what you've read so far, it might sound that committees in general just prevent change from happening and slow down things. 

Committee Driven Development is definitely the sure-shot path to avoiding change. It prevents both you and your organization from doing anything remarkable; but it doesn't stop there.

I am here, dear reader, to tell you, that blown out of proportions, high volumes of overlapping responsibilities and having too many committees in place, is single handedly capable of destroying your next project or even your entire organizations faster than most programmers and organizations think. Committee Driven Development is not just lame; it's dangerous.

The next time, when you're thinking about your company, and feel that you're all amazing people, doing the right things individually, but tend to screw things up when you get in meeting rooms and talk for long hours,  maybe it's because your organization has failed at picking the right Constantine's and giving them enough power and trust to get things done.    

Your job, in some of these situations, is to see if you can become that Constantine.

Don't know how? Go read the James Shore's Change-Diary or see Scott's video on how to make change happen and prevent committee driven development.

I wish you good luck.