In my earlier post, I talked about one reason why you should write an e-book. In the same post, I talked about how blogging is more like bathroom singing and writing a book is more like performing in a live concert.

For the past few days I've been stuck with this idea that will not let me rest in peace till I work my ass off on letting the it gain a form and an independent existence. I've written a couple of posts on the idea, but somehow like an ignored child, the idea seems to demand more of my attention; which I plan on giving it for the next couple of months; and I plan on doing this by writing a dedicated e-book based on the idea.

I love blogging.

I love everything about blogging; There is nothing more rewarding than seeing a meaningful idea that I really believe in, taking a shaping of its own and coming into existence. There is nothing more delightful than pushing the publish button on a post that is about something I genuinely believe in.

The only thing that tops that delight is your involvement, dear reader, through comments, when you go out and post some of these on other sites, when you blog about them, cite them or send emails to me about a post that was written with hours of thought and effort.

This blog, dear reader, is my third place and I am more 'me' here than I am myself in most places including places where I work.

Because the idea of undertaking the e-book has everything to do with fun; done in my free time; it therefore makes common sense to publish the e-book content out on my third place. The e-book therefore, dear reader, will be published out to you; as it takes shape and form.

Going forward I will be publishing posts that I write for the e-book under the category - My books. Because it is going to be mostly unorganized bathroom singing; the posts that will be published will be in no particular sequence. I am hoping that as we move forward the idea will come out in the open; make itself crystal clear and will resonate with you; dear reader.

As always, I would love feedback, criticism and participation from you dear reader. In the weeks to come I will publishing the book here, post by post as it starts taking shape. You reactions; I assume will be on the following lines:

1. Hate the posts.
2. Love the posts.
3. Want to suggest something else I should be covering.
4. Want to point out typos and stuff that should be edited out.
5. Want to contribute and help the discussion grow.
6. Have similar experiences.

The thing to do in all these cases is simple --- drop a comment; blog about it; drop me an email and express your opinions.

Remember, anything that is published here can still change in the book when it is finally published.

Put simply --- participate and contribute.

If blogging is like bathroom singing and writing an e-book is like singing in a live concert; I am going to get up on the stage of a live concert and do some bathroom singing.

This is your chance; dear reader; to boo a bathroom singer in a live concert.

You're not going to miss it; are you?

Looking forward to your participation and contributions.

Oh and before I forget --- wish me luck.

If you have ever been held hostage by an idea which will not set you free till you work on bringing it into a concrete form of existence, you probably know why the act of blogging is serious painful work and at the same time an addictive; highly rewarding and fun filled exercise.

Having said that, for me, writing blog posts is pretty much like free form dancing or bathroom singing.

You don't have to worry about every single idea resonating with your readers. If one doesn't work, they will show up; again; the next day for a completely new idea; a completely new perspective; this time, they may agree to agree and absolutely love your post.   

Writing your own book however, is different.

For a book to succeed; or for you to even attempt to write a book; you need to be hit by a a single insanely strong idea and then work your ass off at it. You need to put the idea on a test of its limit as you probe deeper with a coherent yet remarkable stream of thought.

If your idea is flawed; or not remarkable; you are basically screwed; big time.

You end up making a fool of yourself; after days of writing, editing; re-editing; proof-checking and toiling.

Put simply, if writing a blog is like bathroom singing; writing a book is performing for a live concert.

True it has its glamour associated with it; but along with the glamour; it involves a lot of work; risk of making a complete fool out of yourself and above all, some serious commitment.

Google the topic of writing your own e-book and you'll get a gazillion articles; describing the glamour associated with writing your own e-book and how you can be an overnight success and an instant millionaire by writing your own e-books. Only a minuscule number of these articles talk about the hours of hard work the usually go into this sort of an initiative before anything you write is read by more than an audience of one called you.

Amongst the hundreds of boring self article which are not even worthy of being linked of plugged from this post;  I happened to bounce on one that resonated with me or moved me positively. It was a post by Seth Godin and his advice on writing your own e-book.

It's technically easy and when it works, your idea will spread far and wide. Even better, the act of writing your idea in a cogent, organized way will make the idea better. You can write an e-book about your travel destination, your consulting philosophy or an amazing job you'd like to fill. Seven years ago, I wrote a book called Unleashing the Idea-virus. It's about how ideas spread. In the book, I go on and on about how free ideas spread faster than expensive ones. That's why radio is so important in making music sell. Anyway, I brought it to my publisher and said, "I'd like you to publish this, but I want to give it away on the net." They passed. They used to think I was crazy, but now they were sure of it. So I decided to just give it away.

Writing; is much like singing or exercising your mussels. The harder you work at it, the better you become. That dear reader, is the only true reason why, if you write for your blog and if you have an idea which you believe is worth sharing, you should try your hand at writing a book. You should do it because it gives you an opportunity to do more writing; which is what you love doing.

That, dear reader, is why you need to write a book.

Not because of the five figure income or that celebrity status the millions of readers who go gaga over your book are going to bring you.

You should write a book because you have an idea that will not let you rest in peace till you work on bringing it into existence and the idea or story demands more than just an isolated blog post in order to conveyed articulately.

Writing an e-book is easy. Writing a good one is hard. It's like climbing a mountain. You should try writing an e-book because it lets you see if you 'can' climb the mountain; and once you know you can; you should do more of it.

Why?

Because you can.    

It is really that simple dear reader; it's that simple.

No, you are not going to have a million users drooling over your book.  No you are not going to be a best selling author with a five figure income.

Wake up time. I hate to break the news to you but, that overnight success you might be looking for through your book doesn't exist.

To be honest, you'll be lucky if you don't end up making a fool of yourself with zero downloads.

If you've never done it before chances are high that you'll get sick or tired of it and quit in the middle.

Remember, there are only two reasons why you should write your own e-books; because you really want to; and because you can.

Now; do you want to write your own e-book?

If you said yes, you probably know what it is that you are getting into.

If you said yes, chances are high that I am going to enjoy your reading your book after it is done.

If you said yes, you should write an e-book.

I wish you good luck.

If you've ever been involved in a sales chase for a million dollar project you probably know that folks who market consulting services and software products will go quite far to sell their products or  services to you and close the deal. The whole act of lying about quality of people working for the organization, timelines and above all features that the product being sold has, is an age old Adam's apple folks in the business of marketing software have been tempted to bite for years.  

After all software marketers are experts and their interests revolve around selling you their services. If you have a problem and they have a hammer; they are notoriously famous for making your problems seem like a nail.

Seth Godin in his book titled All Marketers Are Liars describes how all marketers are supposed to indulge in the act of story telling:

Marketers are a special kind of liar. Marketers lie to consumers because consumers demand it. Marketers tell stories, and consumers believe them. Some marketers do it well. Others are pretty bad at it. Sometimes the stories help people get more done enjoy life more and even live longer. Other times, when the story isn't authentic, it can have significant side effects and consumers pay the price. The reason all successful marketers tell stories is that consumers insist on it. Consumers are used to telling stories to each other, and it's just natural to buy stuff from someone who tells us a story. People can't handle the truth.

Seth in his book describes how marketers make consumers and even veteran wine tasters believe that the same wine actually tastes better when tasted in a better glass. The book has other examples including that of a real estate marketer who takes customers around the neighborhood and talks about the various other houses including the lives of people living in those houses.

Seth describes how the individual selling the house is not selling the property he is supposed to sell. He is selling a story.

The book is all about successful story telling.

Story telling that can genuinely create win-win situations both for the marketers and the consumers.

Then there are times when the story telling isn't authentic. The foundations, framework and the very core of the story is built around a lie. That is when Seth warns that the consumer ends up paying the price.

With software however; there is one more group of individuals who end up paying the price of lousy story telling built on utter lies ----- the development team.

My first successful failure was a classic example of the marketing team promising too much with little or no respect for the iron triangle under the influence of wishful thinking and the we-have-a-great-team-that-can-do-it story.

Apart from a few folks, like 37signals, Google and a handful of others who have a great story to tell; almost all other software marketers; especially the ones selling consultancy services; are down right lousy story tellers who don't have anything new to say. Most stories revolve around the same old rather lame ideas:

1. We can meet your deadlines.
2. We can build something really cheap (by outsourcing most of the project).
3. We can deliver quality.

Of course if you pay us more we can do all three and vaporize the iron triangle into thin air; just for you.

If software marketing, for you or your organization, is just about one of these three lame old stories or their combination, your marketing efforts; just like your product website and descriptions; might be downright impotent.  

Pawel Brodzinski describes his rather honest and candid approach to software marketing:

I often try to bring this kind of approach to the table. Too often. You shouldn’t be surprised if you’re a customer and I ask you: “We plan to develop this product for you, does it makes any sense for you or is that just a brain dead idea?” I may also state: “This function would make both your and our lives easier, although I don’t believe they’d allow me to do it for free. Would you find some budget for the feature? I promise the price will be good.” On the side note, if you ever worked with me as a salesperson I know, you already hate me. I guess I must live with that. This approach may weaken negotiating position of my party. Sometimes it is considered as pretty harsh by customers since you occasionally don’t wrap up the truth with nice marketing blah-blah (“No, we won’t build and deploy complex telecommunication solution in a month”). That isn’t playing by the rules and from time to time people find it hard to deal with it at the beginning. However the thing I found out is that when a relation with the customer is already built they start to appreciate this attitude. Having an honest source of information on the other side is quite a valuable thing. Even when the guy is sometimes too honest and too straightforward.

Marketers are supposed to be story tellers. If you are in the business of selling; you need learn the art of story telling and weave stories that are completely new, remarkable and built of a strong foundation of facts; not the same old lousy stories woven around disrespect of the iron triangle. Software marketing guys have been telling these same old stories for years and honestly we're all a little sick and tired of these.

Even if you not a master story teller and can't tell a win-win story which is completely new; you still have a trump-card up your sleeve --- move over to plain old honesty; because honesty in the world of software marketing; as it turns out; is sofa king --- [to be read loudly and very fast] --- extinct that the mere act of being honest will make you a remarkable purple cow and help you not just close your deals or win customers; but have long lasting business relationships.

I wish you good luck.

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:

Sometimes the best way to know what your app should be is to know what it shouldn't be. Figure out your app's enemy and you'll shine a light on where you need to go. When we decided to create project management software, we knew Microsoft Project was the gorilla in the room. Instead of fearing the gorilla, we used it as a motivator. We decided Basecamp would be something completely different, the anti-Project.

They explain why picking a fight helps:

One bonus you get from having an enemy is a very clear marketing message. People are stoked by conflict. And they also understand a product by comparing it to others. With a chosen enemy, you're feeding people a story they want to hear. Not only will they understand your product better and faster, they'll take sides. And that's a sure-fire way to get attention and ignite passion.

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:

When people lack good information, they will invent some information themselves. When they don't know how well their project is doing, they will try to guess. When they don't know how other teams are performing, they will make assumptions. When they don't understand what their colleagues contribute to the organization, they will invent their own reasons. And when they don't know about their manager's personal life, they will gossip about it. To prevent bad information from flowing through the organization you have to give people good information.

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:

Managers should strive to have no secrets. In our organization I made sure that a lot of information is available for everyone. They all can see who is working on which projects, which features, bugs and issues are being handled, and what the team members' evaluations are of those projects. Our people's personal time sheets are public for all, and so are the ratings they give to indicate how happy they were with their projects. My next step will be to share more financial details about costs and revenue for each of our projects. In tough economic times it is particularly important to make everyone understand what the organization's financial performance is. As Jack Stack wrote in his book: only when employees care about financial figures, they will think of ways how to improve them. Some great managers (like John Mackey, Chairman and CEO of Whole Foods Market) even argue that people's salaries should be made public, including their own. After all, if you cannot explain some employee's salary to everyone else in the organization, then how can you expect people to trust you as a manager? I can agree with that. But I also understand that you cannot change an organization's culture overnight. It would be very unwise to start publishing everyone's salaries when there's no culture of doing so. But you have to start somewhere.

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:

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.