I've been asking myself this question a lot lately.  Before we continue this discussion, let's look at how Meritocracy is defined (as by Wikipedia):

Meritocracy is a system of a government or other organization wherein appointments are made and responsibilities assigned to individuals based upon demonstrated talent and ability (merit). In a meritocracy, society rewards those who show talent and competence as demonstrated by past actions or by competition. Evaluation systems, such as formal education, are closely linked to notions of meritocracy.

In the terms of the projects I'm involved with, the biggest for me is the Mach-II Project.  A lot of people on Team Mach-II were asked to be on the team because of pure merit.  Flashback to 2005 when I started with Mach-II and apply merit to me, I would never be selected -- I was too green.  I would say we try to run Mach-II as a meritocracy as much as possible, but I definitely believe there is a bit of benevolent dictatorship in the mix as well.

In the end, not every decision can be made by committee. At least a "good" decision made.  Some of the problems with committees are while they take account of a bunch of different view points they are terribly slow to move and sometimes produce less than desirable results.  Then introduce politics (especially when financial implications of multiple parties are involved) and things typically grind to a halt.  Committees only work when all parties involved want the same result.  I have little patience to be part of committees / processes that are jaded that progress can be made despite have multiple parties with different financial interests.

This is one of the reasons why committees by company / association appointment in open source just don't work.  Money will nearly always triumph over pure idealistic concerns even when "doing the right thing" would be better.  Does this mean that humans are just greedy by nature? I'm glad I don't have to answer that question (it's been a funny premise on the Simpsons before as well).

People appointed by merit (and not company / employer association) typically share a common goal.  However, who is to break a stalemate?  This why most "meritocracies" still have some person in the "dictatorship" role.  In regards to Mach-II, I definitely play this role.  In the Rails project, DHH still plays the role of the dictator when needed.

So yes, I believe meritocracies can exists, but in certain situations somebody has to play the role of "dictator" / "president" / etc.  However meritocracies need transparency to function properly.  Transparency will be a subject for a future blog post.

I've been invited to speak at cf.Objective() 2010.  I am co-track chair for Tools & Integration track on the conference's content advisory board. I've gotten a sneak peek at the line up of sessions and speakers -- this year looks amazing!  This is definitely one CFML conference you do not want to miss.  I'm proud to announce that I will presenting on the following topics.

Speedy Websites Through Better Front-End
We'll be using tools like YSlow and Google Page Speed to diagnose issues in which we can improve the front-end performance of a website.

Open Source Tools for Debugging
The title is pretty self-explanatory, but we'll be looking a variety of tools that can be used for debugging web applications.  Everything from Javascript to HTML to webservices to file systems to Java.

Living in the Cloud: CFML Applications on Google App Engine
I'm co-presenting this with Matt Woodward.  Cloud based computing, while a buzzword these days, is something that very compelling. So come see how cloud computing differs from traditional application development and how it can open up a different world for your applications.

Simplicity, Integrity and Velocity: What's New in Mach-II
I'll be co-presenting this with fellow Team Mach-II members Matt Woodward and Kurt Wiersma.  We'll be looking at the all the features in the almost ready for gold release of Mach-II Simplicity (1.8), what is already there for Mach-II Integrity (1.9) and hopefully a sneak peek at Mach-II Velocity (2.0).

I'll be sharing more on my presentations in the next few weeks, but take the moment to take advantage of the early bird pricing for cf.Objective() ends on January 29th -- so register now!

I've been working on a brochure style site for a friend this week.  The budget is nothing and I'm doing this as a favor for my friend so it's my time. Instead of doing the same old, I decided that I should try something new and learn since I'm donating my time.  I hope to be posting more about using Google App Engine (GAE) as free hosting for CFML applications.  GAE is cloud computing and it does turn the usual concept of building applications on its head.  Since GAE's daily http request limit for the free account is 1.3M requests, I don't foresee any issues with overing over our quotas.

The application I'm building is using Mach-II Simplicity (1.8) and is running on Open BlueDragon (GAE Edition).  My friend wanted to use SES URLs so I investigated to see if the SES URL filter that is usually bundled with Open BlueDragon was commented out in the web.xml file.  It was not even present in the file (whereas in the normal OpenBD edition it is commented out) so I was a little nervious this wasn't going to be possible.  Instead of wasting time researching, I used GAE's nifty one click (ok, it's two clicks and your Google account password) deployment option to just try by testing it.  Here is the snippet I added in my web.xml right at the top after the <web-app ...> node:

<filter>
    <filter-name>SearchEngineFriendlyURLFilter</filter-name>
    <display-name>SearchEngineFriendlyURLFilter</display-name>
    <description>SearchEngineFriendlyURLFilter</description>
    <filter-class>com.newatlanta.filters.SearchEngineFriendlyURLFilter</filter-class>
    <init-param>
        <param-name>extensions</param-name>
        <param-value>cfm,cfml</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>SearchEngineFriendlyURLFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Bam! I deployed it to the cloud and it worked.  SES URLs on OpenBD GAE is a go!  Thought I would share it with the world.

So is the "build it bigger faster" theory a sound long term design plan for open source software? Do more and more options to accomplish essentially the same task make a better piece of sofware?  The answer to both questions in my opinion is a resounding no.  The "faster is better" theory does not work either unless you have great software architecture in place.  Implementing new features without pause or forethought is dangerous at best and a possibily a harzard to your health if things go hopelessly wrong.  This type of development is an easy to get into because it is any easy way to please users quickly and some people have dubbed this "cowboy coding".  However, it leads to poor architectural choice down the road and literally can paint you into a corner.  While it is not a hard or fast rule, projects that frequently publish "upgrade guides" when new versions are released indicate the use of the  "build it bigger faster" theory.  Upgrade guides are usually written to help users "fix" their code because the sofware project  made poor architectural choices that require revisions later on in order to make up for shortcomings.

(via http://www.mach-ii.com/index.cfm/go/blog:showEntry/entryId/8C7B1B44-D975-986B-D9228DA788AE2724/)

I originally wrote this for the Mach-II blog, but I thought I should repost a link to this on my new Posterous.  I've been thinking about how long something should "bake" before it should be allowed to into the world.  There is a lot of open source software out there just doesn't get the refinements to it that make working with it a pleasure.  Instead of thinking of this like something you can stick into the oven for a few more minutes, I like to think of good software development like the process of baking a good loaf of bread.  Here are few items / processes for baking a nice loaf of bread and the corresponding software development part:

Premium Ingredients
Well, if you're going to bake a killer loaf of organic pumpernickel bread -- you should start with the best ingredients right?  Situations in software development where you need to turn lead into gold will never turn out.  The old phrase of garbage in equals garbage out applies here.  Let's start with nice stoned milled organic grains and filtered water for our bread.  In the terms of software development, the analogous part would be thorough research, a good strategy and an architecture plan (meaning you understand the needs of what needs to be accomplished).  Just because you have the perfect recipe and all the right ingredients doesn't mean it's going to turn out.  This leads us to...

The "Right" Tools
I don't know if you noticed, but I didn't lump in developer knowledge or skills in the last point.  You cannot just buy experience and knowledge as they must be accrued over time.  Just like in bread making, you might have access to a wood-fired, stone bottomed oven, however there is an art to using that as a tool.  If you aren't careful, you might just bake blackened mounds of burnt crap.  If you are just getting started with bread making, a loaf pan and a modern gas-fired oven might be easier for you to managed and give you better results.  With time, you'll learn the tricks of using that $40k brick oven, but just realize things take time.  And time is can be your best tool because...

Practice Makes Perfect
If you've ever seen me speak at a conference, you've probably heard me say "software development is an iterative process."  Talk about a boring phrase, albeit accurate.  A more sexy phrase is "practice makes perfect."  Let's pretend it's the very first time you're baking a loaf of organic caraway rye bread.  Doesn't matter if you have the best ingredients, the perfect recipe and the right equipment, you'll first time won't be that artisan quality you're looking for.  I think a lot of the time the phrase of "well, it's works...right?" is used as a justification for not refining the end product.  There is an art to refining what you are doing and don't think you'll get it right at the first pass.  Actually, I'll be the first to admit that many years ago I had a complex about "doing it right the first time."  This was bad because I hemmed and hawed over the small minutia -- thinking that if I did not get it right the first time -- the whole pot would go sour.  Now my philosophy is "do it your best the first time" and have the humility to realize and correct your mistakes in order to make a more perfect result.  Sometimes this means you have to correct small defects in your code or add in new features.  Other times you'll  have to start a fresh because your implementation is like somebody that just peed in the pool -- the yellow cloud underwater is an indicator that you shouldn't hang around.

Putting It All Together
So how do you make the best bread?  Talk to your fellow bread bakers!  Nothing exists in a vacuum and it's important to have a sounding board for your ideas.  Sometimes this is easy because you work on a team of great people and sometimes you have to go it alone because you're the only person on the product.  I tend to work on small teams and so my sounding board has to be me sometimes.  No, I don't have multiple personalities, but I do talk out loud to myself quit a bit.  Most of the research out there indicates that vocalizing your thoughts uses different parts of the brain than just thinking about them.   So I'm just utilizing all the parts of my brain.  I bet everybody has experienced a time where you just can't figure something out and you head over to the next cube or fire up your chat client and after the first 30 seconds of discussing something -- voila -- you'd go "d'uh" and figured out your problem before even explaining the whole thing.  I recommend that talk to yourself first before wasting an other developer's time and possibly interrupting their zone.  There is an art of knowing when to ask for help and when self-reliance is needed.

In closing, I hope to refine my bread baking concept over time.  Right now I think it's at soda crackers level.  Maybe I'll attempt a better version again soon.