By nature, I am a very peaceful man that loves all of God’s creatures; however, it has been a long time opinion of mine that Paris Hilton must be assassinated for her crimes against humanity. Paris Hilton embodies everything that everybody hates, and as a shocking result – everybody hates her.

Here is the kicker – I see these same traits in some very arrogant developers. So what can we learn from Paris Hilton the developer?

Never Learn Anything

Why learn a new language when you already know at least 3 keywords in the language you grew up with? Once you realize that “hot” is not a keyword in Java (although I am officially proposing it should be), perhaps it is time to grow up and break out of your shell.

Being lazy and apathetic to learning truly is this generation’s new learning disability. Continuous learning is a cornerstone to a healthy lifestyle, but absolutely essential to stay in the software development limelight. Don’t be a dummy and think that you can get away with your current skills for the rest of your career.

Think You’re The Shit

Thinking that the center of the universe is you is a classic developer mistake. You are not that special. There are millions of people that can also develop software, and just because a small group of people depend on your skills does not give you a right to think you are better than them. Guess what buddy, you are dependent on the rest of the company for that paycheck every month.

Look Busy And Accomplish Nothing

Go ahead, run from meeting to meeting looking like a chicken with it’s head cut off. People will (and unfortunately do) view that as productivity. However, the more time you spend looking productive the less time you are being productive.

Productivity is measured with tangible results, not with time and energy spent.

Blame Others For Your Mistakes

Who just broke the build? Oh girlfriend, it must have been that bitch Nicole.

Blaming others for your mistakes is just weak. You suck because you suck. Get over yourself and go learn how to fix it…oh yeah…I forgot you have the learning disability…sorry…

As we know, egoless development environments are necessary for a productive learning environment for our teams; however, I have been knocking around the idea of conducting an experiment and completely eliminating any traceability within the software process.

Here is my thought: with the exception of “fail fast” pieces of the software process (such as the build server), why is it necessary to know exactly the when and who someone created a feature or a bug?

Knowing this information does not eliminate nor lessen the burden of correcting the problem – the only thing it promotes is negative finger pointing.

The most logical arguments for granular code/feature traceability would be:

• Provides visibility of per person velocity
• Creates a sense of accountability
• Allows for possible learning opportunities

I can not argue that these are good points, and that I myself use traceability to my advantage when keeping a team on track. However, I will argue that all of these points are covered if you have hired the correct people and run them in an efficient manner. For example:

• Personal Velocity – Visibility can occur during daily stand ups and weekly powerdowns
• Accountability – Why the hell do you have people on your team that you don’t trust?
• Learning – Either the bug is a bug (and no real lesson is to be learned), or senior developers did not properly guide less experienced devs through a design problem

My point is that the problems that traceability solves, do have equivalent solutions that occur at a much more proactive level.

The majority of times, the people requesting this level of traceability end up being people that have very little participation in the project (Scrum chickens). Guess what they use it for…a quick gauge for “the blame game”! I have never seen this information used for the benefit points listed above at the managerial level. At this level of traceability analysis it is all about who fucked up (which must be the logical reason why the project is doomed).

Use traceability to your advantage so you can better react to the “now” and forget using traceability for what has happened – no reason to go on a witch hunt…you have bugs to fix.

I have come to grow very tired of Microsoft’s approach to building and marketing software to the masses, and here is the simple reason why:

When you build software for everybody, you build software for nobody.

I don’t remember where I picked up the term “customer polarizing” (I believe it was 37 signals), but it really resonated with me in terms of software. If you attempt to satisfy everyone, you will in the end satisfy no one due to feature bloat. And as we all know, feature bloat leads to UI bloat, which yields code bloat, which yields performance bloat….well you get the idea…it becomes an unusable, unmaintainable, piece of crap.

Now the reason why I say “mediocre giant” is because it is my belief that you can become very large and successful attempting to please everyone all the time as this is very alluring to potential customers.

However, you will always be mediocre (as apposed to great) because you will have never polarized anybody into either loving or hating your products.

Apple is a great example of this theory. They have products which drive people fanatical or left out in the cold. They will never put a SCSI port back on a laptop. They will never put a floppy drive back into a desktop. They are polarizing people, and as a result their “true customers” love them for it.

To take this a step further (just for a quick tangent), the majority of customers who demand these bastardizations of your products probably will not become a customer let alone a repeat customer and fan – so why attempt to please them in the first place and drive away your fans?

With the recent ASP.NET MVC seeming to be the first exception to this rule [in a long, long time] – Microsoft only will deliver software that is feature bloated to the point where it will work OK in 90% of business, instead of concentrating on software that works GREAT in 40% of businesses.

Just like the RoR team, concentrate on making GREAT products, even if at first they seem to be targeted at a small niche of people. Your raving fans will promote your name much farther than you can with any marketing effort, and you won’t feel as if you had to make a lot concessions with your product.