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?

A couple of years ago Amazon Announced Job Descriptions for their Two-Pizza-Teams. Amazon had figured out a simple rule for staffing their teams which limited the task force at Amazon to five-to-seven-people-per-team, depending on their appetites and turned Amazon into a very healthy company. The rule for staffing a team at amazon was simple - "If you can't feed a team with two pizzas, it's too large."

This is one simple rule tons of so-called-huge software development body shops around the world and the so-called-managers who work for these body shops just don’t get it, even today, almost two years after Amazon proved to the world that it works.

I recently interviewed a manager who worked in a huge Indian body shop who claimed during the interview that he had - "managed a project with fifty resources" - directly reporting to him on a day to day basis. Apparently, it seemed like he had managed many other similar projects in the past and as usual was having a hard time taking this thing to production. He specialized in what I call - going round and round the infinite loop of failure - which is why he was looking for a change.

On the other hand, at work, we had a project with many similar and additional complexities which was blossoming it's way to success and was being run by a self managing team of five to seven really smart individuals.

So, why is it that when a team of fifty bodies in a body shop was struggling at a project and failing pathetically, one or two small teams of three to five programmers were executing much bigger and complex projects flawlessly?

For a shorter answer - smaller self-managing teams of shameless developers and one man armies are much better and much more efficient than huge teams of mediocre bodies who are purely interested winning a war against the client and not shipping genuine value.

I’m not an authority in the craft of building software, but, just for the sake of saving your time, based on my past projects, experience and lessons, you can take my word for it. On the other hand, If you have time to kill, and seek a more logical answer based on data and would rather not just take my word on this one, read on.

Years after Frederick Brooks broke out the fact that adding manpower to a late software project makes it later in Mythical Man-Month, huge body shops, and so-called-managers around the world found another silver bullet.

Add More Manpower to a Project right from the very start! (Especially if you have an outsourcing body shop in India and thousands of relatively cheap developers sitting on the bench.)

This rule is perfect. In-genius! But it has just one problem – it does not work.

Nine women getting together cannot speed up the process of creating a baby. Whether they are involved from the very start or towards the end does not matter.

Doug Putnam does an excellent objective analysis on how teams work and which teams sizes work best in most medium scale project development scenarios. His Research (graphs borrowed from his web-site) seems to suggest that smaller teams are better:

After presenting his analysis on over 491 projects Doug sums up his finding:

The goal of our research was to find optimum team size for building medium sized information systems. From the 491 projects that were analyzed we would conclude that a 3-7 person team has the best performance (3-5 would be the best, but 5-7 people is a very close second).

He concludes with words of wisdom which almost sound like a warning to the careful listener:

Next time you are planning a project think hard about the optimum staffing levels because it can clearly have a significant impact on the overall results. This study gives you some insights into an application and size domain where many systems are being built today.

While concluding the article he also goes ahead to describe why smaller teams work better. Go ahead, click the link and give the article the read that it definitely deserves.

Now pause a while dear reader and think about the virtues of divide and conquer. While Dough talks about 3 to 7 person teams for medium sized projects ask yourself if you can break up your bigger projects into smaller sub-projects. If you think hard enough, much like Google and Amazon does, inevitably the answer would be yes.

Every now and then I meet budding managers who take pride in mentioning the number of people who report to them. Every now and then I meet budding developers who take pride in mentioning how big the team size of their current project is. It seems mostly cultural. So if you are working with a group of fifty other developers you must be building something seriously important, right?

Wrong. Based on my own personal experience, with fifty plus bodies of mediocre developers,  you could in fact be building a perfect piece of crap that may never see the light of production or is not even fundamentally usable.  

If you are a budding developer take pride in what you and your team innovates and ships not in how many bodies your current project team consists of or how many documents you or these bodies are writing. If you are a budding manager / team lead take pride in working with a small group of smart individuals who can maneuver, communicate and innovate rather than large multitudes of clueless programmers who can't program.

Growth is inevitable, specially if you are successful. Besides growing your team in numbers, grow them in ability to work smarter. Make sure you are growing with the right people who are capable of shipping by breaking the infinite loop of failure rather than going round and round in it.

Divide your projects into sub-projects and your team into individual self sustaining teams who can run those sub-projects without any hand-holding. Remember, every class library or DLL in your project can be a individual project by itself, led by a small self sustaining team if needed. 

A fifty or hundred developers reporting directly to you is something to worry about, not something to be proud of! What are you waiting for? Go get two pizzas and if you can’t feed everyone who works directly with you, on those two pizzas, maybe it’s time to divide your teams and conquer your projects!

Tom DeMarco and Timothy Lister start their book Peopleware – Productive Projects and Teams, with a thought worth harping on:

Somewhere Today, A Project Is Failing. Since the days when computers first came into common use, there must have been tens of thousands of accounts receivable programs written. There are probably a dozen or more accounts receivable projects underway as you read these words. And somewhere today, one of them is failing. Imagine that! A project requiring no real technical innovation is going down the tubes. Accounts receivable is a wheel that's been reinvented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.

Software Legend Steve McConnell throws some light on the same mistakes people in our Industry have been making again and again, so many times, for so many years, that he calls them Classical Mistakes.These are the kind of mistakes which can easily cause yet another simple accounts receivable project to fail once again.

Both, the thought of an accounts receivable system failing and classical mistakes are thoughts that have some sarcasm, irony and a lot of bitter truth in them. Both these thoughts are in-fact quite scary if you harp on them for too long. And then you begin to wonder why.

Why do the same kinds of projects keep failing over and over? Why do programmers keep making the same kinds of mistakes again and again? Why can’t programmers of this planet, for once, spend some time and learn how to program?

DeMarco and Lister provide a clue to the alert reader who can read between lines and come to his own conclusions in their book:

The statistics about reading are particularly discouraging: The average software developer, for example, doesn't own a single book on the subject of his or her work, and hasn't ever read one. That fact is horrifying for anyone concerned about the quality of work in the field; for folks like us who write books, it is positively tragic.

Notice the use of the word horrifying? Yes, it is in fact much more than just horrifying.

It is a well known fact that today most folks in the business of crafting software don't give a shit about learning the craft of building good software and the sorry state of our industry allows them the luxury of staying blissfully ignorant.

Software Development as it stands today, is probably the only field where you can afford to be the man responsible for the failure of multiple accounts receivable systems and be rest assured that there will be a body-shop out there willing to hire you at a higher salary and a better designation to give you the job of building another accounts receivable system just because your resume says you worked on multiple accounts receivable systems. 

I do not know why or how but an obsolete version of my resume which has not even been touched, updated or posted anywhere in the past five to six years, keeps fetching me job offers, interview calls and emails from Indian body shops which I politely keep turning down and sometimes even ignoring.

It’s tragic.

Not because someone somewhere out there wants to hire me. That’s the good part. There’s nothing tragic about that. It’s the best professional complement you can receive as a software developer. This year for instance I received a couple of offers from folks who knew me or folks who had read this blog, had read one of my articles, had taken the pains to get my references from folks I had worked in the past and then decided to make me a job offer. Even though I turned them down, the offers did come as professional compliments which ended up making me feel really good.

Having said that however, most other offers I ended up getting this year have been from complete strangers, based out of an obsolete outdated resume that has neither been updated nor posted anywhere for over five to six years! The fact that there are recruiters out there working for so-called-big-body-shops who want to hire me, without knowing anything about me, based on a resume which hasn’t been updated in the last five to six years, speaks at-length about the recruiter, his desperation to find anyone who is ready to call himself a programmer, the shortage of programmers in our business and the desperation of the organization he works for.

And, that is in fact both tragic and scary.

I even have a name for this type of a software-development-eco-system which constantly encourages crappy programmers to enter the industry, make classical mistakes and keep failing project after project. I call this the Infinite Loop of Failure.

The Infinite Loop of Failure explains why another simple accounts receivable system can manage to fail even after the millions of man-hours of computing experience our industry has behind it. Let me illustrate the Infinite Loop of Failure using my artistic skills:

A huge part of the universe in which we live in includes:

1. People who build software – we refer to them as programmers; depending on their way of working, sometimes I address them as bodies, so-called-programmers or even Fred.
2. People who hire people to build software – we refer to them as companies or employers; depending on their way of working, sometimes I also address them as body-shops.
3. The People who ultimately pay, to get software built – we refer to them as clients; these are people who know nothing about building software, have one or more bitter experience with software development from their past where they've been bitten by some body-shop and a bunch of clueless bodies. Now they want to spend as little money as possible. These are people who need help in getting their problems solved by building systems that work.

I write this post with a heavy heart, but the fact is that most of the people who form these three categories are totally lost and looping around at different stages of the Infinite Loop of Failure playing different roles in the loop’s infinite life cycle. They are in-fact helping the loop gain momentum and stay alive.

A huge part of our industry, is doomed to a future where the same kind body-shops will keep recruiting the same kind of programmers, who will keep making the same kind of mistakes on the same kind of projects, using the same crappy processes and methodologies and will keep meeting the same kind of failures. As you read this post, a huge number of so-called-programmers are spending their lives looping in this Infinite Loop of Failure as they hop from one job to another, one designation to another and one project to another, earning peanuts more for every hop.

What makes the problem difficult to solve however, is that this multitude of so-called-programmers is largely un-reachable and cannot be helped by posts like this one. You can’t get them to know about this Infinite Loop of Failure. They are not exactly reaching out for technical blogs, reading posts like this ones, writing their own posts, learning how to become a better developer, participating in user-groups, asking or answering questions in forums or buying copies of Code Complete, Pragmatic Programmer, the Software Project Survival Guide and the like. Long story short, they don't care - because our Industry allows them the luxury of not caring and getting away it. 

I’ve met my share of 501 programmers around the world and I've also met my share of programmers who are so depressed about programming that they write depressing poetry.

I’ve had my share of failures as I pushed budding college students to read and write blogs, pushed budding project managers to read Software Project Survival Guide and pushed budding programmers to read Code Complete.

Most of them are usually too busy to read a book, read a blog or start their own blog. They are too busy firefighting their current project which is doomed to fail because they are making the same classical mistakes. Others are busy playing musical chair with their jobs. They are standing right on the edge of the Infinite Loop of Failure preparing to enter it.

I've had my share of failures as I try to nudge them to the brighter side and try to stop them from entering the loop. Some don’t even make an attempt to read a book, blogs or start their own blog. Others start for a couple of weeks - under the gush of enthusiasm, at times even just to impress me - and then stop. I've seen multiple other colleagues at work fight this same battle of motivating the unmotivated programmers and face the same problems.

If you’re trying to convert a programmer who has already entered the Infinite Loop of Failure and is addicted to going around in circles, it’s usually a losing battle, at-least a very difficult one. Having said that, I agree that that we need to continue motivating the masses and keep trying relentlessly to pull the ones walking on the thin line of the loop to the brighter side of the line.

It is a fact that these masses consist of a huge percentage of our industry, and if they don't care about software development, if you think logically, it translates to a very strange fact:

A huge percentage of the people in the craft of building software do not give a shit about the craft of building software.

And that is a scary thought. Don't you think?

But there is a silver lining to the dark cloud. The sorry state of affairs in our world of software development makes it really easy for shameless thick-skinned programmers like us, which includes me who is writing this post, and you dear reader who cares to read it, differentiate ourselves as one man armies or kick ass programmers and shine.

We can distinguish ourselves very easily! Not because we write code that no-one else can write but because we know that most of the times we write shitty code with bugs. Because we know that the Infinite Loop of Failure exists! We also know that this loop can be broken by exchanging thoughts through books, sharing ideas through blogs and learning from not just our own mistakes but from the mistakes of the people we work with and share ideas with.

We know that, to break the Infinite Loop of Failure all we have to do is find a job we love, join a team we love working with, stick to developing deeper roots and in the process have loads and loads of fun doing what we always loved doing – which is building software that is nowhere close to perfect, but that ships, gets the job done and keeps improving and getting better with us! 

Of course, we are no different from the ones who do not care and yet so very different. Just like them, we are bound to make mistakes. Some of these may be small, some may be colossal. Some can be fixed; some cannot be fixed for life and will keep us wishing if only we could go back in time and fix them. But every single mistake will at-least teach us a lesson and turn us into better individuals. Mistakes are good, as long as we stop making the same old lame mistakes and make all new ones; As we make all new mistakes we are bound to keep learning something from these fresh new mistakes and that knowledge will eventually keep us out of the Infinite Loop of Failure.

As Jeff Atwood points out in his post:

I say the more failed projects in your portfolio, the better. If you're not failing some of the time, you're not trying hard enough. You need to overreach to find your limits and grow. But do make sure you fail in spectacular new ways on each subsequent project.

So, do you know a couple of folks who could never ship a module on time but who managed change three jobs in the last one year? Do you know folks who never cared to read a book or a blog but were happily failing one accounts receivable system after another? Or do you know a few developers who are basically smart but standing on the edge of Infinite Loop of Failure? Jeff Atwood's suggestion on reducing daily WTF snippets might turn into a beautiful New Year’s gift you can buy them this year:

Let's take a break from our regular programming to consider how we can prevent WTFs from happening in the first place. If you're reading this, you probably don't need our help. But your fellow developers do. Take less capable developers under your wing. Mentor them. Provide them with guidance. Invite them to a user group meeting. Email them blog links. Expose them to essential programming books like Code Complete and Don't Make Me Think. In extreme cases, maybe they legitimately picked the wrong profession and should be gently nudged into some other role.

Go buy them a copy of Code Complete before it’s too late. If they do read it, nudge them to read a couple of blogs and push them into starting their own blog. Show them the path to shamelessness. After all, in the years to come, we don’t need more failed accounts receivable systems, do we? Who needs more Daily-WTF Code Snippets in our project code-bases? I don't. Do you?

As a new year rolls towards us, let’s continue relentlessly trying to help the programmers walking on the thin line of the Infinite Loop of Failure move over to the brighter side.

As for us, you dear reader and me – people who care to reach out for books, blogs, user-groups, web-casts, open-source code-bases, fellow-developers, colleagues or any other source under the sun that can help then become better developers and better individuals, let’s continue to break the break the Infinite Loop of Failure, this year and year after year. Not because we want to change the world, but because we know that it can be broken and because we can have fun breaking it! 

Dear reader, this new year, I wish you luck. If you’re going to be making mistakes, I wish that you make all new mistakes. And by the way, this year, as you slog away at becoming a better developer, a better professional and a better individual, day after day, don’t forget to play your part in breaking the Infinite Loop of Failure. You owe it to your profession, you owe it to your fellow programmers and above all, you owe it to yourself!