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! :)

For quite a bit of time I haven’t been talking about TacticSheet. For those of you who do not know or have forgotten TacticSheet, allow me to begin this post by refreshing your memory. TacticSheet is a free open source Timesheet entry system which we’ve been building using Visual Studio 2008, C# 3.0 and LINQ to SQL. For more information on TacticSheet, how you can download it, try it out, participate or contribute in it's development visit this URL.

We’ve been moving slower than expected in TacticSheet because:

1. My day time job has been keeping me busy where I’m working on getting a lot of goodness we have on the banking side released as a service for free.
2. We’ve been busy hiring; which means lots of interviews and lots of thought provoking discussions with candidates which is just helping me realize how weird our industry is becoming. This of-course has been translating and resonating into some of my posts lately. :)
3. Visual Studio 2008 RTM introduced a couple of minor breaking changes to TacticSheet which was originally started on Beta 2.0 of Visual Studio 2008.

Excuses aside, we’ve got back to work, slow and steady and will continue to push new features into TacticSheet and make it more and more stable and usable.

Here’s what was checked into the Source Forge SVN a few days ago:

Changes to Allow TacticSheet to build and Run on Visual Studio 2008 RTM

We started TacticSheet with Visual Studio 2008 Beta 2. Most breaking changes we encountered were in the LINQ to SQL side. As promised, TacticSheet now builds and runs on Visual Studio 2008 RTM version.

A Brand New UI

I’m no graphic specialist; having said that I’m pretty proud of my Photoshop skills. I’ve also advised programmers to learn and pickup a little bit of UI designing. This check-in of TacticSheet introduces a light, crisp and slightly more professional UI than the pinkish UI we started off with. We hope you enjoy using it.

Clear Distinction between Advanced Allocations and Simple Allocations

In TacticSheet there are two ways to allocate an employee to a project. The allocation can be a simple allocation which basically means that you want the employee to be associated with the project for the entire life span of the project. For advanced allocation you only want him to work on the project for a given date range.

The previous check-ins of TacticSheet we picked up the start date and the end date of the project and used those to determine the duration for which the employee can work on the project even in case of simple allocation. As simple as the approach was, it was leading to problems when you want to extend the duration of the project after the allocation has already happened.  

In this version we explicitly tag a simple allocation as a simple allocation. Which means a simple allocation has no start date and end date associated with it and auto extends as life / duration of the project extends.

Tons of Bug Fixing and Validations

We’re not yet as stable as I would want TacticSheet to be. I would encourage everyone to play around with it and file bugs if you find them. Our firm belief that good software is never complete drove us to keep testing TacticSheet like Crazy, fix bugs and add more and more validations.

If you’re playing around with TacticSheet or towing with the idea of using it when it goes to the Release stage be rest assured that we would love to be involved with and fix Tactic-Sheet issues as and when they found. The whole point of releasing TacticSheet is to be able to support what we build and this check-in was one more step in that direction.

We’re Far from Done

During this time when I went silent on TacticSheet multiple people (much more than I had expected) asked, buzzed or emailed wondering if TacticSheet was dead. Far From Dead; it’s alive, breathing and taking baby steps at growing.

For all those who have subscribed to our mailing list and offered help in form of participation, thank you so much for your continued help and support. We really look forward to more of it!

Continue to watch out for new features, more stability, better UI in the coming weeks.

With the release of Microsoft MVC framework we've also been evaluating and considering the use of the framework in TacticSheet but that would mean moving some bigger pieces around and a lot of playing around with the framework before we take the plunge.

I'll be writing a series of posts which will describe my evaluation of Microsoft MVC framework as I play with it and try and try and use it to address some real life problems TacticSheet needs to address.  The posts will be focused on describing what's going on in my head as I decide whether TacticSheet adapts this technology or continues on it's current custom MVP plus Ajax based implementation. Expect additional posts on these in the near future.

Stay tuned for more features, interesting technologies and more open source goodness. :)

Johnny Knapsack's story in the 15 Second Principal by Al Secunda is insightful. 

The story goes on to describe how Johnny keeps running with the same heavy knapsack on his back and winning every single race till he reaches one of the most important race of his life - the Olympics trails, where he loses by fraction of a second.

When advised by American coaches that he could have easily made up the split second difference and won the match had he not carried the heavy knapsack on his back, Johnny replies:

The coaches response to Johnny's reply is soul-stirring and applies to a lot of us; not just in our lives but in the way we run our projects as well:

In multiple organizations, client offices and development shops around the world I see programmers carrying knapsacks of their perceptions on how successful projects aught to run, on their backs.

Every now and then it is not un-common for me to come across a business analyst who believes that a twenty page login use-case just has to be written or a test lead who believes that a twenty page login test case has to exist, or a developer who refuses to code without a detailed lengthy low level functional specification document, irrespective of how simple the system is.

When I started moving my teams to Agile in some of my older projects and client offices, I would see a few developers panic with the idea of not having Dead-lines and Gant-charts. Some who had never shipped, because they changed job faster than typical Big Design Up-front Projects are usually delivered, were concerned with the whole idea of shipping every month.

A young enterprising tester complained that as a project manager I should estimate for him and give him deadlines instead of having him estimate for his own tasks. Another developer kept complaining that we didn't have detailed project wide documentation and if someone left, the project would be in a bad shape.

We continued to have folks fully involved in estimating for their tasks and people (including the developer who was most worried about people leaving) did leave smack in the middle of the project but the project ended with a very successful implementation and a very happy client, way before the expected end date. By the expected project end date we ended up delivering way more features than promised because agility had lightened the heavy knapsack we were carrying. Some of us, had seen the light.

Even now, as you read this, countless development shops around the world are focused on have enterprise wide project processes, practices and methodologies which every team in the organization is forced to follow.

With software development, the whole idea of carrying knapsacks on your back as you run is lethal and yet very common. We are handed over the knapsack on our first race, usually by our first organization.

Johnny's story however, has a happy ending: 

Just like Johnny some of us are lucky enough to see the light and lighten our knapsacks as we move forward. For others though, every race after that is essentially a replay of the first one where they carry the same heavy knapsack of their processes and methodologies on their backs.

Whether you are following CMM, RUP or Agile, always keep asking yourself: Are your processes and practices adding genuine value or are they just added items in the knapsack you are carrying on your back? If they are just added items which are slowing you down, consider lightening your knapsack before you lose your most important race.

I leave you, dear reader, with questions worth harping on - Are your projects really successful? Are they successful because of your processes or in spite of your processes?  Are you just following what traditional project managers and your older organizations taught you, just like Johnny followed his father's advice?