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

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

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

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

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

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

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

Wrong.

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

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

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

Jeff Atwood questions how important writing code really is:

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

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

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

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

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

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

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

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

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

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

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

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

What's your favorite web-site?

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

Google.

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

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

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

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

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

Here's how Wikipidea defines a leech:

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

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

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

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

Bullshit.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Something deep down inside tells me that I'm heading for a controversial post so let me go into a CYA exercise first. Here we go:

Doesn't reading this post after reading the above CYA Declaimer seem meaningless? I've already told you that I am clueless about the topic I'm going to write on and that I take no ownership of the words I'm going to write. In other words, if the information presented here is outright wrong, it's your problem. My ass is covered.

Doesn't this attitude completely de-motivate you from reading this particular post any further dear reader? Humor me, read on. I have a point to make. I promise.

The folks who wrote screen-scraper have a manifesto which describes what they refer to as the 15% rule:

Fair enough. If I put myself in a client's shoes, this seems to be virtually the only paragraph in the whole manifesto that I don't have a problem with.

I tell myself: I'm the client and these folks are a little worried about me blowing up the scope so they want to make sure they are covered. That's Fine. But then I read on. From this point on, the manifesto seems to get overly defensive and if I'm playing the client, I see myself knitting my brows at almost every other paragraph. For example:

Followed by a contradicting statement:

The Manifesto seems to miss out on one simple fact of life. Nobody cares about you! Your best friend betrayed you? Your girl-friend dumped you? One of your older clients cheated you? I know It's very important for you, but you know what, in the real world where we live, no-one cares! Specially your new clients. They don't care about any of this crap. Surprise!

I completely understand your need to share your past tragedies with your new clients but is it necessary? For a change, let's pretend they cared.

Let's pretend they wanted to know more. So, what was the name client of this client that insisted a lot of changes? What went wrong with this project? Can you also publish the contact information of these clients in the manifesto so that we can contact them to hear their side of the story?

See? You don't want them to care. Right? So why bring it up?

Besides, this is not your blog or your personal diary. It's an official project document. If you must commit to 15% more and no more, say it in a line or paragraph, highlight it, ask them to sign it, in a simple professional way and if they don't, explain why you added the line or paragraph to them. If they still don't get it, move on.

As you scroll through the document it gets worse:

The client telling me how much analysis to do or if analysis is needed up-front sounds scary. Go ahead, read the document in it's original form. Throughout this document, there are tons of CYA statements all over the place. Every time the author feels he is about to scare away the client, he is kind enough to point out that things are in the 'gray' area and that there is a We're-Going-To-Be-Nice-To-You section in the document.

Of the multiple places where I disagree with the document, one place where I completely beg to differ with this document is on it's stand on bugs:

Ok, so let's pretend I'm the client here; and what are you guys making me sign? A manifesto where you are not going to spend more than 15% of the project time on enhancements and bugs, not more than 3% on Analysis (unless I pay for more) and you're going to make me decide how much analysis I need. But when it comes to your figures on bugs, you expect me to 'trust' you. Convenient, eh?

Can we please also attach numbers to what happens if I find a Gazillion functional bugs in the project? Do I pay 'x' percent less? Can we also quantify 'x'? What if a thousand of those are critical which end up taking more time, which results in breaking the 15% rule this manifesto is setting? How much discount do I get?

What if some of these bugs are so critical that not being able to fix them makes it impossible for me to take the project to production? Do we just break the relationship on a it's-not-you-it's-me note and remain friends happily ever after or do we compensate each other monetarily?

Am I sounding mean here? As a client if you expect me to 'trust' you when you say you won't write bugged code, do you mind trusting me when I tell you that I won't blow up the requirements? You've been burnt by a bad client? I've been burnt by bad consultancy firms and programmers who can't program.

You've lost money? I've lost money too. You think there are bad people out there? Me too. It's your software industry that's famous for sucking clients like us into the infinite loop of failure. You guys as software developers are the most hated professionals in the world after lawyers and with a document of this sort in front of me, I find it very difficult to trust anything. I'm just way too nervous. Sorry.

Then there are references to the client deciding if he wants QA done on the project:

As a client, if I asked you to reduce testing time and deliver a bugged system in production, that's ok? You still want business from me? Seriously, why even talk about it? If it's important for you to ship quality just add a 10% QA code cost and a 5% project management cost and make a bold statement stating that you don't do work that's not quality. Why haggle? The We-Are-Going-To-Be-Nice-To-You section is the icing on the cake:

We'll be hard-nosed, we hope that you'll be nice to us and in the end we'll all be most successful if we treat each other fairly and kindly... yeah. Here's what we just went though:

1. A five page CYA document that makes me (the client) decide how much time you should spend on analysis, testing and project management.
2. A five page CYA document that ensures that your business prospers even if my project gets completely screwed.
3. A five page CYA document that ensures that you can get away with a Gazillion functional bugs by putting in just 15% more effort and time (everyone knows time spent on something is not always directly proportional to results achieved).

And why was this detailed five page manifesto necessary? Because you feel your older clients cheated you and that your future clients (me included, if I am pretending to be the client) might be similar. Awesome. After going through it, I feel really motivated to sign this document and treat you fairly and kindly.

Jokes and sarcastic humor aside:

Don't get me wrong. I know some of this documentation is necessary, particularly if you are an independent consultant working and getting paid by the hour. But then in almost all companies, NDA's are necessary and most employees don't mind signing them. However, when a company starts frisking their employees before they get in the office every day in the name of protecting intellectual property, it becomes a joke.

Similarly, CYA documents like this one might be necessary evil on both sides and a must have for some projects. The 15% rule might be acceptable to most clients if you put it in a line or two or maybe a small paragraph in the statement of work, highlight it sufficiently and get them to sign it. It's when you prepare elaborate documents giving out unnecessary and irrelevant details to the client that it becomes a joke.

If you genuinely intend to help the client, slide in one paragraph on the 15% rule in the scope of work document, get them to sign it and then forget about it. Help the client with walking the middle path on analysis and give them genuine value for money! Use constant feedback and quick iterations to guide them and keep your project on track. Use your art of prioritization to help yourself and your client both. Use it to control the scope and make the project successful. 

The five page manifesto is just a Glamorized CYA document, nothing more, nothing less.

Yes, make them sign on a Statement of work that has that a paragraph on the 15% rule, but work your ass out so that you would never have to show them that paragraph and remind them they signed it particularly during the later stages of the project. If you have to, you have failed.

Maybe you failed at analysis, maybe at implementation, maybe at building a relationship, maybe at communication; but none the less, if you have to show that paragraph to your client, you have failed.

Remember your end goal is not to put in 15% extra effort and then run as fast as you can. If your client doesn't use your product, it's your failure.  After all you and your client are allies in the same battle.

If you disagree with what I'm saying here and think that CYA manifestos and declaimers are effective and work, don't bother to leave a comment or email me. Read the declaimer on the top of my post? It says I have no clue of what I'm talking about, doesn't it? With that declaimer in place, I guess I can say anything-what-so-ever about this manifesto and get away with it. I'm covered! Right? :)

Seriously, I'm lucky to have a job with a firm that works with a completely different business model and I don't have to worry a whole lot about this crap. Personally I've had my share of demanding clients, but none of them have been evil. 

If you disagree, that's fine. Let's discuss. I would also like to take responsibility for what I write and accept both comments and emails on this post. So go ahead, send me that hate mail if you must. Tell me that I don't belong to this world and I'm just looking for Utopia. Tell me what an impractical jerk I am!  :)

In one of my earlier post I announced that I will start playing around with Microsoft ASP.NET MVC framework with the intent of seeing if I can find a compelling reason to replace the custom implementation of MVP (based on Billy McCafferty's article)  that currently powers TacticSheet with a Microsoft ASP.NET MVC implementation.

As I started playing around with ASP.NET MVC I discovered that Microsoft ASP.NET MVC isn't just about separation of concerns. As Scott Hanselman right points out, to a typical ASP.NET developer, it's a completely new philosophy:

After years of View-stating and Post-backing joining a completely different band that plays completely new music is a big change. A change this big also demands that folks wanting to be quick adopters and play this all new music will need to spend a bit of time and understand a lot of new concepts  out there.

Most concepts with ASP.NET MVC Framework are easy to understand. If you're someone who believes in simplicity, writing clean testable code and controlling your own angle brackets ASP.NET MVC is mostly very straight forward to figure out. If you have been following posts by Scott Guthrie, posts by Phil Haack and posts by Scott Hanselman, none of the MVC concepts should sound new.

Where I did have to pause a bit, think and spend a little bit of time was while figuring out how Routes and Routing Tables work with the ASP.NET MVC framework. If there were simple explanations of routing and how one could make routing dance to his tune out there, at-least I wasn't able to find these simple explanations.  

After wasting quite a bit of time trying to figure out how default routing in ASP.NET works I decided to write this post, so that you dear reader, won't have to spend time going through multiple blog posts. I've always thought of myself as a hands on person and I don't like reading a lot of theory just to understand fundamental concepts. Here's my humble attempt to simplify how Microsoft MVC routes and routing tables work and bring it to dummies like you and me. :)

Let's get started!

Without  going into a lot of theory let's just start a new ASP.NET MVC Project and take a look at our global.asax file. Here are the first three lines you would see in the Application_Start.  

Let's analyze these three lines and what they mean.

Using line one we're telling ASP.NET MVC Framework that my URLs are going to be following the pattern of passing a controller name followed by action name followed by an a parameter called 'id'. Line 3 tells ASP.NET MVC that when I do hit a URL that follows that pattern it should use the MvcRouteHandler as it's route handler.  MvcRouteHandler is the default Route Handler shipped with ASP.NET MVC framework and for most applications (unless we have a special need to write our own route handler) that's pretty much what we're going to use.

Line two indicates that if I forget to give the name of an action in the URL while browsing / running the application, ASP.NET MVC invokes the "Index" action by default and if I forget to specify the "id" in the URL, it passes null to the action method by default. In the above declaration I'm not allowed the luxury of forgetting my controller name in the URL, but if you wanted a route that allowed you that, you could do that as well. (We'll shortly see how).

All of this basically means means that if I had the following code snippet in my HomeController, the OpenEmployee method would get invoked with Id passed as 2 if I entered the URL - http://[ApplicationUrl]/Home/OpenEmployee/2

For a typical ASP.NET developer there is a little bit of magic going on here. The magic is mostly inspired out of design paradigms like Convention over Configuration and some of it also seems to have slight inspirations from Duck Typing.

Notice how you didn't type "HomeController" in your URL. You just typed "/Home/OpenEmployee/2". The moment ASP.NET MVC sees the controller name in your URL it uses 'convention' to figure out that you intend to invoke a class which has the name you have specified in your URL followed by the word 'controller'. So it ends up invoking the 'HomeController'.

Additionally a little bit of magic you might have noticed in the above code snippet is that we have not specified anywhere in our code that the Id in the URL has to be treated as an integer. However the parameter in the OpenEmployee method is defied as an integer. Which means when you pass "/Home/OpenEmployee/2" ASP.NET MVC assumes that 2 is an integer, implicitly converts "2" to an integer and passes it to your Open Employee method.

On the other hand if your OpenEmployee expected a string called id, ASP.NET MVC would figure out that the conversion to Integer from your URL isn't necessary. The below code snippet still works:

In the above snippet because your controller now expects a string you could pass anything to it. In other words URL's like  http://[ApplicationUrl]/Home/OpenEmployee/2 or http://[ApplicationUrl]/Home/OpenEmployee/Hello would pass "2" and "Hello" to your controller.

Let's get back to the global.asax and take a look at the next 3 lines of the routing code that was generated by Visual Studio 2008:

Remember I told you that you also build a route where the name of the controller would be assumed by default if you didn't specify it ? The highlighted lines of code above are an example. By now if you've got to the soul of what we've been talking about the three lines highlighted above shouldn't need any explanation. In the above three lines we're telling ASP.NET MVC a few very simple things:

If someone hits the URL "Default.aspx" (and does not follow the controller/action/id pattern) we just want the default controller to be "Home", the default action to be "Index" and the default 'id' to be null. This is useful because when someone tries to visit your application using the URL http://[ApplicationUrl]/ IIS 7(based on it's default settings) will attempt to open default.aspx. When this happens ASP.NET MVC will automatically instantiate the Home controller and will invoke the default action 'Index' on it.

This logic also explains why all Microsoft ASP.NET MVC applications must have a Default.aspx in it's root even when the file isn't directly used or invoked manually:

Ok, so far so good. This post was written with an intent of making the basic concepts of ASP.NET MVC routing concepts stupid simple to understand.  Now that we understand these concepts let's see if we can tweak our routing slightly and make it dance to our tune a little bit.

In most Web based applications if you are using SQL server identity columns (or any column that's an auto-generated integer) as primary keys the whole approach of having id's being passed to Action methods directly from the URL makes a lot of sense. However, at times you want to pass more that just the id from the URL.

For example in TacticSheet, where a person can be assigned to more then one project I would want to open his allocation to a specific project; this means that to open allocations of an employee I would have to include "/Allocations/Open/5"  in the URL, where Allocation is the controller, Open is the action and 5 is the ID of the employee whose allocation I want to open.

But in the above approach we have a problem. An employee might be allocated to more than one project and I want to open his allocation for a specific project. In other words, I want my URLs to work like this - "/Allocations/Open/5/Projectx" - where Allocations is the controller, Open is the action, 5 is the ID of the employee and Projectx is the name of the project.

If I can trap this URL from my controller and have both '5' and 'Projectx' passed to my Action method, I can effectively open employee 5's allocation for project x.

To  archive this I open my global.asax and add one more route to it:

Notice how I added projectname to the URL and told ASP.NET MVC framework that it should now start expecting project name after the id; so now paths like "/Allocations/Open/5/Projectx" become perfectly valid paths in my application as long as we have underlying controllers and actions which can handle these paths. 

So let's go ahead and create my AllocationsController and add the following Action method to it:

Now when I visit the URL - http://[ApplicationUrl]/Allocations/Open/5/Projectx it results in the Open action method of the AllocationsController being invoked. 5 is passed in as 'id' of the employee that you want to open and 'Projectx' is passed as the project name of the project for which you want to open Employee ID 5's allocation.

If you've followed along, the basic explanation of how routing works and how you can add simple routes yourself might sound stupid simple. If you're looking for more control over your routes, refer to Scott Guthrie's post on routes.

Ben Hunt has written an Excellent book on Web Designing; but when it comes to his own blog / web-site, Ben is guilty of breaking rule number three of Thirteen Blog Clichés . Jeff Atwood describes:

Go ahead click the link to the online version of Ben's book which is a freely available on his web-site. There are ads of other books that Ben has written on the page but when you try to find the author's name for the book that you are reading - zip! nothing!

I landed on this page through a Google Search Query and while reading the Web 2.0 design guide I had a hard time finding out that Ben was actually the author of this excellent book which imparts words of wisdom to web developers and web designers around the world on how to build effective web designs.

It was only when I navigated back to the primary domain (web-design-for-scratch) that I found out that Ben owned the entire site and that the book belonged to him.  Ben Hunt, in spite of being an amazing web designer, a great writer and a web guru, is guilty of making me think and that, according to Steve Krug, is an offence. Take that, Ben! :)

Jokes apart, for me Ben's book is as good as Don't-Make-Me-Think when it comes to building web-sites; and what' makes this book even better is that it's available online for free.

You there. You, yes you. If you're a web designer or a web developer building web applications you need to stop whatever it is that you're doing and read this book. Now! No, I don't care if you are busy; I don't care if have a lot of work to do; I don't care how many other usability and web design books you've read; go tell your boss you won't be doing anything for the next one day and read this book word by word.

Seriously,  Read the book; chances are, you'll probably take home more than one idea on web design that you always believed in but couldn't quite pin down.

The book highlights a lot of concepts on Web Designing but to me the concept that stands out the most can be summed up in one word:

Simplicity.

Just like simplicity in coding, building features, design and development, simplicity in web design also has it's own ability to stand out and distinguish itself from the crowd; in an elegant subtle way. When choosing between attractive-and-complex vs. simple-and-elegant I would prefer simplicity blended with elegance any day. After all, Simplicity Rocks!

"That's a great design! You've really proved that you're great at Photoshop and other designing tools. Now dump it and start fresh." - I often see myself giving this advice to web developers and graphic specialists around the world. Specially the ones who tend to use a lot of jazzy bells and whistles, beautiful smiling faces and rich color combinations in their web applications.

Don't get me wrong. I have nothing against a lot of jazzy bells and whistles, rich graphics and beautiful smiling faces on a web-sites. If your application, web-site or the point you're trying to convey to the world / your customers / your visitors demands that, by all means, go ahead and use all of these. If not, I don't see the point of having an elegant design that's much more attractive than the point you are trying to get across.

In Ben's word:

Here are some web-sites that I've often cited as examples:

None of them are rich when you consider them from a graphics perspective. Ever wondered why? Is it because these organizations cannot afford a couple of kick-ass web designers who know how to get a lot of jazzy images and bevels done?

Ben's book uses words from Antoine de Saint-Exupéry, the classic author who wrote soul stirring books like The Little Prince, to illustrate the point:

I think these words sum up exactly what I mean by "You've really proved that you're great at Photoshop and other designing tools. Now dump it and start fresh." much more articulately than I could have ever said it.

Early on in my career, on my way to office each day, I would pass a bill-board sign of a cellular service provider. The billboard hoarding had a very wise slogan - 'you don't always have to be loud to be heard' - as strange as it may seem the board had a lot of impact on my life.

With web site design, I think the most effective sites are the ones where the designers are not trying to 'prove' anything to anyone or becoming loud to be  heard. The most effective web-sites today, are sites where the web designers are making bigger points and conveying bigger and better ideas with lesser pixels - using a calm, subtle, non-intimidating and helping tone.

Dear readers, fellow Web Developers and Designers, for today I leave you with one thought to harp on and one assignment to execute.

Thought: Software is composed of technology, underlying platforms and above all end users and how they perceive and experience the application. If your User Interface doesn't gel with the world and ecosystem around it, it's useless.

If your user interface doesn't get to the heart of the problem you're trying to solve with your application or convey the point you're trying to make with your web-site, by showing up blazing fast and then guiding the user with a simple non-intimidating and simplistic tone, particularly without overwhelming or distracting them, you may have come up with a really beautiful design and proved that you're an expert when it comes to Photoshop, Illustrator and tons of other design tools but in the end it doesn't matter!

If your excess pixels end up taking too much time to load or end up innocently confusing your users by pulling their attraction on just the bells and whistles instead of the core functionality, you have missed the whole point and failed completely!

Yes, you have a beautiful User Interface, but is that really the point? Is that the only thing defining your success as a web developer or web designer?

As for the assignment, go read the really invaluable and free advice on making your Web User Interfaces better directly from the expert's mouth. Quick! :)