News and thoughts from the people at EllisLab.

EllisLab Hiring Technology Architect

Posted by Derek Jones on July 11, 2008

EllisLab is happy to announce an opening on the development team for a new Technology Architect:

The Technology Architect will have responsibilities covering many aspects of software development, from maintaining the current code base for ExpressionEngine and CodeIgniter to developing new tools and applications under the direction of the CTO. The Technology Architect will also be required to help keep documentation for products up to date.

The Technology Architect is a full-time position (part-time is also available).

Full job descriptions and qualifications are available on the EllisLab Jobs page.

To apply email . Your email will include a formal resume, examples of previous work, and be a showcase of your use of email as a primary communication tool.

CodeIgniter Community Voice

Posted by Leslie Camacho on June 09, 2008

Today we start publishing the CodeIgniter Community Voice, a CodeIgniter Blog column from the mind of Derek Allard that will highlight members of the CI side of the EllisLab community. CI expert Elliot Haughin gets things started with CodeIgniter is a heck of a can opener.

CodeIgniter is one of those things that just does a job perfectly. Take for example, the humble can opener. Whilst there may be a few other ways to open a can of tuna, the can opener just ‘works’ it serves a simple, yet extremely efficient purpose, and does its job with perfection.

Head on over to the CI Blog to read all of Elliot’s contribution. Are you a CI fan with something to say? Have your voice heard.

Allard Receives “Masters of Education” Degree

Posted by Leslie Camacho on June 03, 2008

I’ve been pursuing my Master’s of Education part-time since 2003. I took a year and a bit off in the middle of there somewhere, but other then that, I’ve been pretty steadily marching towards it for 5 years. In April I finally finished off the last of my course requirements, and last week I got the official paperwork; I’ve finally finished off the degree. Huzzah! I’m now legally allowed to call myself a “Master”, um… not that I ever would. Oh no wait, I would.

Stop by Derek’s blog and give him a hardy slap on the back.

ExpressionEngine 2.0 File Manager Preview

Posted by Leslie Camacho on May 20, 2008

Derek Jones has posted a preview of the EE 2.0 File Manager over on the ExpressionEngine blog. Enjoy!

A fresh new site

Posted by Rick Ellis on May 19, 2008

A little over a year ago, right before SXSW, we launched new websites for all our domains. Site development always takes longer then you anticipate, so it was a mad dash to get the sites finished in time.

Due to the haste, the EllisLab.com site never quite got the attention that the other sites got. I loved the cartoon representation of me, but the rest of the site was kind of ho-hum.

A few weeks ago we began talking about adding an employee intranet area to the site to serve as our staff home base. That project fell into my lap since everyone else was too busy. For about a month I dragged my heels, feeling very little motivation to tackle the project, until it finally occurred to me why: I wasn’t happy with the site itself, so the idea of adding onto it wasn’t exciting me.

So rather then fight my feelings, I decided it would be fun to roll up my sleeves, blow the dust off of Photoshop, and design and build a completely new site. With that, I’d like to unveil our new site. I hope you like it.

Justin Hurlburt, the EllisLab Code Mechanic

Posted by Derek Jones on May 19, 2008

All of us at EllisLab would like to welcome Justin Hurlburt as our new Code Mechanic. Finding our Code Mechanic has required patience. In fact, this is the first that we’ve ever had to advertise outside of the EllisLab Network. After over a month of searching we found Justin, who fit precisely what we were looking for, and there was much rejoicing.

Justin is an experienced web developer, having created multiple web sites and services, maintaining commerce sites, providing support to both development teams and end users, all working with technologies that EllisLab employs in its current products. As a Code Mechanic for EllisLab, you’ll come to know him quickly as his role will primarily be that of providing assistance to the Technical Support and Community Service staff in resolving difficult issues and finding and fixing bugs. And of course, vacuuming the CTO’s couch to pick up what’s left of the box of Gobstoppers I dumped into the cushions.

Welcome aboard, Justin!

Paul Burdick steps down, Derek Jones steps up

Posted by Rick Ellis on April 30, 2008

It’s with some sadness that I announce today that Paul Burdick is stepping down from his position as Chief Technology Officer, a role he has held for over four years, in order to pursue some personal goals. Although Paul will continue with us in a reduced capacity, he is being replaced as CTO by Derek Jones.

They say that in life, timing is everything. In 2003, fresh out of college, Paul was hired by the Oregon Wine Board to build a website using our first generation publishing system, pMachine Pro. That site had a number of needs that were not able to be met natively by pM Pro, so Paul, despite never having coded anything in PHP before, rolled up his sleeves and figured out how to develop those features. He then generously donated his new code back to our community, which is how I first met him.

I remember looking at his code and being blown away that he had only been coding a few weeks. He was a natural. He also happened to live in the same city as I did, and as luck would have it, my little company had grown to the point of needing some development help, so I offered him a job. Paul became employee number three. There was me, a guy named Chris doing tech support (who left the company years ago), and Paul.

At the time Paul came on-board, I was a few months away from unveiling ExpressionEngine, the secret new project I had been working on. In order to stay focussed on EE, I turned pMachine’s development over to Paul; a risky move for sure, given how little experience he had. To Paul’s credit, he took the challenge by the horns, dove head first into the code, and single-handedly developed the very next release of pM Pro. A natural indeed.

As good as Paul’s technical skills were, his work ethic and commitment were even more impressive. Paul immediately became my trusted right-hand man, and for the past four years has been an integral component to our success. During those early years in particular, Paul was more like a brother than an employee. I can’t express how grateful I am that Paul emerged in our forums one day, and helped shape who we are today. I couldn’t have done it without his help.

A couple years ago, we had a similar good fortune in finding Derek Jones. He had been participating in our forums, having built a couple projects using our software. We needed to grow our team just as Derek’s career was transitioning, so we offered him a job. Similar to Paul, Derek was very new to programming when he started, but he had that special mojo that enabled him to learn rapidly and get productive very quickly. In less then two years Derek has gone from having little programming experience to becoming CTO of our company. Impressive.

Paul, and later Derek, taught me my philosophy on hiring: Hire people who are brilliant, who get things done, and who show great aptitude—and this is important—even if they don’t have a particular skill-set. Skills can be learned. The other stuff can’t.

So today marks a day of transition. Paul Burdick is leaving to spread his wings, tackle some new challenges, and meet some personal goals. And Derek Jones is emerging as the cornerstone of our technical team. Paul leaves a big void to fill, but fortunately we’ve had some months to make the transition internally, and he will still be with us in a reduced role, so our development goals shouldn’t be affected.

Thank you for all you’ve done for us, Paul. You’ll be missed!

Comments can be found in this forum post.

New ideas

Posted by Rick Ellis on April 24, 2008

John Cage, the famous avant-guard composer, wrote a piece entitled 4’33” (Four minutes 33 seconds), in which the orchestra sits silently, playing nothing during that time. His point was to challenge the notion of what constitutes music.

Brian Eno said that repetition is a form of change. He too was challenging convention.

Paul Graham says that ideas are all around us, but we ignore them because they look wrong. He’s right. Often, things don’t look right to us until someone else does them first. How many times have we said “I wish I had thought of that!”, in response to a clever new concept?

I’ve had a new product idea for about a year. It started as a vague concept that stemmed from my discontent with the state of blogging. Most blogs have a very familiar format, a standardized navigation, categorization, and structure. There is a fundamental similarity of approach, regardless of topic. I’m a little restless and bored with the state of blogging, frankly. I feel like we’re ready for a new iteration of the format.

These feelings produced a small fragment of an idea, which I’ve been wrestling with for the past year. It’s taken many months of thought, tinkering, and staring out the window to hone the idea into something that resembles an actual workable concept. I’m still not in development of the idea, but I finally have enough of a handle on it to consider moving forward.

The point is that ideas take work. They don’t just appear out of thin air fully formed and ready to craft. They come in fragments. In bits and pieces. Ideas are like an onion. You have to peal the unnecessary petals away in order to get at the core. The simplest ideas often take the most work, mostly rejecting all the extra junk that isn’t needed. Linda Tischler said it best: “In an Escher-like twist, the technology that’s simplest to use is also, often, the most difficult to create”.

So don’t get frustrated if you seemingly don’t have any good ideas. Each of us has ideas, great ones. But they require that we think unconventionally, and most of all, that we be willing to work at them. Thomas Edison said that genius is 1% inspiration and 99% perspiration.

How to be creative

Posted by Rick Ellis on April 21, 2008

Hugh MacLeod’s brilliant essay offers 36 tips on being creative:

Ignore everybody.
The idea doesn’t have to be big. It just has to be yours.
Put the hours in.
If your biz plan depends on you suddenly being “discovered” by some big shot, your plan will probably fail.
You are responsible for your own experience.
Everyone is born creative; everyone is given a box of crayons in kindergarten.
Keep your day job.
Companies that squelch creativity can no longer compete with companies that champion creativity.
Everybody has their own private Mount Everest they were put on this earth to climb.
The more talented somebody is, the less they need the props.
Don’t try to stand out from the crowd; avoid crowds altogether.
If you accept the pain, it cannot hurt you.
Never compare your inside with somebody else’s outside.
Dying young is overrated.
The most important thing a creative person can learn professionally is where to draw the red line that separates what you are willing to do, and what you are not.
The world is changing.
Merit can be bought. Passion can’t.
Avoid the Watercooler Gang.
Sing in your own voice.
The choice of media is irrelevant.
Selling out is harder than it looks.
Nobody cares. Do it for yourself.
Worrying about “Commercial vs. Artistic” is a complete waste of time.
Don’t worry about finding inspiration. It comes eventually.
You have to find your own schtick.
Write from the heart.
The best way to get approval is not to need it.
Power is never given. Power is taken.
Whatever choice you make, The Devil gets his due eventually.
The hardest part of being creative is getting used to it.
Remain frugal.
Allow your work to age with you.
Being Poor Sucks.
Beware of turning hobbies into jobs.
Savor obscurity while it lasts.
Start blogging.

Are you authentic?

Posted by Rick Ellis on April 11, 2008

One of the biggest challenges of growing a company is maintaining your authenticity as you move beyond the small founding team.

We’ve been trying to fill a couple new job openings at EllisLab. As I sift through several dozen applications, what I find most glaring is that very few of the candidates are currently part of our community or culture. Some do have experience with our products, and they possess the necessary qualifications, but without that integration they feel like outsiders to me.

Historically, people from our community have emerged to fill new roles with us. It’s been a very organic process, where we get to know someone on a personal and professional level well before we ever consider them for a job. Unfortunately, that process won’t scale, so we must recruit candidates in a more traditional way as we grow.

In order to maintain our authenticity and core values, must all new candidates come to us already integrated into our culture? Ideally, yes, recruits should already be part of our family, as it makes the process much more seamless and natural, just as a Harley rider is a better candidate to work at Harley Davidson then someone who doesn’t ride.

Unfortunately that’s not always realistic, so the challenge becomes how to best integrate new employees. Harvard Business Review asks a similar question in a fictional case study called Authenticity: Is It Real or Is It Marketing?.

Would you be missed?

Posted by Rick Ellis on April 09, 2008

John Moore has a great series of posts asking whether certain brands would be missed if they disappeared (hat tip Seth Godin). He asks:

Does [insert your brand] provide such a unique product and customer experience that we would be saddened if it didn’t exist? Does [insert your brand] treat its employees so astonishingly well that those workers would not be able to find another employer to treat them as well? Does [insert your brand] forge such unfailing emotional connections with its customers that they would fail to find another company that could forge just as strong an emotional bond?

Tough questions indeed…

The Gentle Art… of Business

Posted by Rick Ellis on April 06, 2008

I’ve been studying Brazilian Jujitsu for the past two years. If you’re not familiar with Jujitsu, it’s the foundational ground fighting component of UFC. The easiest way to understand Jujitsu, although it’s an oversimplification, is to think of it as wrestling with chokes and joint locks.

Jujitsu means “the gentle art”. It’s based on the premise of using your opponent’s energy against them. If someone pushes, you pull. If they pull, you push. It’s about redirecting your attacker’s energy, diffusing it, so you can control them and ultimately win—and in a way that doesn’t harm them or you.

Since I’ve taken up Jujitsu I’ve come to look at size and strength differently. Jujitsu isn’t about force on force, it’s about using leverage, and angles, and technique. It’s about brains, not brawn. You never match strength against strength, you exploit your opponent’s weakness with your strength. Your legs, for example, against their weaker arms.

I mention this because I see many parallels to Jujitsu in business. We often attempt to battle our business competitors head on, but that’s a bad strategy, especially if you’re smaller. It’s much more effective to find where your competitor is weak, or where they do not want to go, and focus your energy there. A pinpoint application of focussed energy often beats a larger, more dispersed force, just as a wrist lock can bring a 200 pound stud to his knees.

In Jujitsu, body positioning is the most important element. The goal is to achieve positional dominance. Without it, you’ll never get a submission. Similarly, in business you must find where you can be dominant, even if it’s a small niche market. Get strong where your competitors are weak. Don’t try to beat them at their game, find your own game, a better game.

Timing is critical in Jujitsu too. Every technique has a start, a middle, and an end. If you start the technique at the wrong time, or if you try to finish a technique too early, forget it, it won’t work. Being sensitive to the proper timing is key. The same applies to business. Remember the axiom that it’s better to be first then best. Don’t wait, move quickly when you see an opportunity. The first move is the most important one, as all subsequent ones rely on it.

It is said that Jujitsu is a game of inches, meaning that a tiny shift in body position or angle can have an immense effect on leverage. A small shift in business strategy can create an entirely different outcome as well. Analyze your market, know your competition, and study your customers in order to find the holes, the gaps, the opportunities. Become a black belt in your particular market.

It’s human nature to fear the bigger, stronger person. But often, those big muscles require lots of fuel, they tire quickly, and have limited range of motion. In Jujitsu you need isometric strength, muscular endurance, mobility, and a high level of conditioning, not a “beach body”. Similarly, keep your business agile, lean, and fluid so you can take advantage of opportunities, and be willing to work harder and more relentlessly once you seize them. Build the right kind of strength and conditioning.

The biggest difference between someone new to Jujitsu and an experienced player is their economy of motion. A black belt moves very deliberately, efficiently, and calmly, with no wasted motion or energy, while a white belt expends enormous energy in all directions at once. A beginner doesn’t know whether to push or pull, so they do both, burning themselves out. In business, model yourself after the experienced Jujitsu player. Be calm, assertive, and move deliberately toward your goals. Don’t fight obstacles, go around them. Don’t panic when something goes wrong, see it as a new opportunity. Don’t fear your competitors, keep moving toward your objective.

Open Source vs. Commercial

Posted by Rick Ellis on April 04, 2008

There has been a long-running debate as to the merits of Open Source vs. closed source (commercial) as a software development model, so I thought I would post my thoughts on the matter.

Note: When I refer to “Open Source” I’m talking about the licensing of the product. The source code of ExpressionEngine is open and almost entirely unrestricted, but it’s not distributed under an Open Source license. Conversely, CodeIgniter, our application framework, is distributed as Open Source.

I’m about to make a statement that might ruffle some feathers, but I believe I’m qualified to make it, since we develop software under both licenses:

Commercial development nearly always produces more compelling applications, faster development, more consistent code, more responsiveness to users, and provides a better customer experience.

If you are a proponent of Open Source, show me the equivalents of Photoshop, DreamWeaver, MS Office, Illustrator, ProTools, TextMate, QuickBooks, FinalCutPro, Reason, Performer, iMovie, Transmit, SuperDuper!, AutoCad, Avid Xpress, any video game, and thousands of other successful applications. For every product I listed (and admittedly, my list is Mac-centric since that’s what I use) there are many viable commercial alternatives, but few Open Source ones. The ones that exist can rarely match the capability or raw development speed of their commercial counterparts.

The only Open Source companies that can compete on a similar level are those that generate enough revenue from ancillary sources to support a dedicated development effort, like PHP, MySQL, and Linux. But for every MySQL there are thousands of others that can’t create a model that produces a highly competitive product. In some limited realms like operating systems, server platforms, and small web applications Open Source has emerged as a competitive model, but these are exceptions that have secured significant outside funding, or that are small enough to be maintained by a tiny development effort. Overall it’s not even a contest.

I do acknowledge that there are some advantages to Open Source, like the ability to use the code in any manner, for any reason, and in any way a user sees fit. However, these are usage benefits, they are not development benefits. In other words, the end user gains some rights, but these come at the expense of the developer’s ability to focus on the code, affecting how good a product he can offer.

When you sell software, as we do, you are in fact being paid to write code. When you give it away for free, as Open Source companies do, you have to find a different way to earn your living, thus limiting the time you can spend on development. Which business model do you think will produce code faster? Which model enables the business to focus on its core mission? Which model places more emphasis on the needs of the end user? Which model generates working capital, enabling the business to expand, hire staff, and offer new opportunities to their customers?

We produce our own Open Source product, and our solution to moving it forward efficiently is to build our commercial application on it, so that we can invest our core development efforts into it. Without that, we would not be able to put much time or resources into that project, limiting its growth. On a personal level, I like Open Source a lot. But as a development model it does not generally enable better development.

Another important point is that commercial software companies usually take better care of their customers than Open Source companies. Why? Because when happy customers correlate directly to your ability to earn a living you’ll work harder for them. Obviously Open Source companies care about their users too, but the dynamic is different. The level of responsibility a developer feels toward the end user is not as great when the user has gotten the app for free. There is not the same sense of urgency to provide tech support, bug fixes, and add new features for free as one does toward those who have paid for a product. For those of us who develop commercial apps, its those features and benefits that help sell more software, so we focus on them.

At EllisLab we employ several tech support professionals, and our development team provides support too. Support is provided at no charge as an added value of purchasing software from us. Our response time is very fast, and we have a total commitment to it. There is no Open Source equivalent. The only way to get official support is to pay for it through a support contract, or hope that a community member will assist. The former costs money, the later is not as consistent, nor does it have the follow through, nor can bugs be addressed officially and fixed immediately when they surface. When you factor in the benefit of support, the speed at which we resolve bugs and take care of problems, the cost of ExpressionEngine is quite small. And for those who rely on ExpressionEngine for business, our support and responsiveness offers great peace of mind.

Passionate advocates of Open Source tend to tout the benefits and minimize the downside. Yes, there are some benefits to Open Source, but there are certainly negatives. From my vantage, in terms of developing a better product and being responsive to ones customers, a commercial development model usually wins.

Lest I be branded a heretic let me say that I love many Open Source apps. Heck, we’ve built our entire business upon two of them: PHP and MySQL. But we didn’t choose PHP and MySQL because they were Open Source, we chose them because they were the de-facto standard for web application development. Had either of these apps not been Open Source we would have still used them. It isn’t Open Source that makes PHP and MySQL compelling, it’s the fact that they are the best in class and have huge market share.

I’m not an absolutist with regard to licensing. I look for the best applications that meet my needs. In some cases it’s Open Source, in most cases it’s not. But my criteria is not based on ideology, but the more practical desire to fill my toolbox with the best available tools. I don’t care much about the licensing of the software I use, nor do I worry whether the software will be around forever. I care whether they are the best in their genre and whether they meet my present needs. For me, the best are usually commercial apps.

Be Number One

Posted by Rick Ellis on March 28, 2008

One of my favorite business sayings is: If you can’t be number one in your market, redefine your market.

Whatever your category of business, if you are not in the top one (or maybe two) positions, you need to define a new category in which you can be number one. If you have small market share and you’re battling against a much larger competitor, instead of a better marketing strategy, you need a better category.

Jack Welch, the ex-CEO of General Electric, who is considered to be one of the best CEOs ever, insisted that every single product under the GE brand had to either be number one or number two in its respective market, or he would either kill the product or find different management. During his tenure, Welch grew GE from 14 billion to over 400 billion.

I’ve always tried to apply that rule to my own business. My goal for ExpressionEngine, for example, has always been to develop a it as publishing system that bridges the gap between a simple-to-use blogging tool and a full-featured content management system. There are lots of blogging tools on the market, but none of them have the power to meet the intense site requirements that EE can. And lots of CMSs, but none with the ease of use of a blogging tool or EE. Expressionengine is singular in that category. We are number one.

This rule doesn’t only apply to product businesses. Are you a web designer or developer? It’s critical that you find a category that lets you occupy a unique position in the minds of your customers. Don’t spend your energy battling for customers in a saturated market, and against other firms with no discernible difference. Figure out what you can be number one in, and shout it from the rooftops.

Tesla, Edison, the electric chair, and new technology

Posted by Rick Ellis on March 27, 2008

Nikola Tesla, my favorite of the great inventors, who was arguably the most inventive genius of the last century, invented the first successful way to create alternating current. To this day, whenever we plug anything into an outlet, we’re using his AC Motor design. Along the way he also invented the xray, the radio, the first wireless remote control, and about two hundred other things.

Before AC there was only direct current, which is the principle that batteries operate on. The use of DC became widespread in the United States around the turn of the last century thanks to a guy named Thomas Edison, who you might have heard of. Edison invented lots of nifty things too, and among other things, owned lots of power plants all over the east coast.

DC, however, is a terrible form of energy to transmit over long distances since wire tends to act like a resistor, gobbling up the energy. Houses closest to the power plants had bright light bulbs; the ones farther away had proportionally dimmer ones.

Despite the shortcomings of DC, Edison had a vested interest in its continued use since he was making a fortune from it. Then along came Tesla with his superior AC, threatening to put Edison out of business.

Not one to go down without a fight, Edison tried to convince the public that Tesla’s design was very dangerous by electrocuting small animals to death using AC current. He then built an electric chair and used his political influence to get Auburn Prison to execute prisoners with it. Eventually lots of other prisons installed his chair as well. Nice fellow, that Tom.

A common expression at the time when someone was executed using Edison’s electric chair was to say “he got Westinghoused”, a reference to George Westinghouse who had backed Nikola Tesla financially while developing AC.

Despite Edison’s attempts at FUD, AC eventually won the battle, and today, no one would dream of using DC current. It took many years, however, for people fully embrace AC.

I’m reminded of this story when I think about the stages that people go through when adopting a new technology, or simply a new product. Just because you offer something better or different does not mean people will buy it. Often, they have too much invested in whatever they currently use.

Windows users migrating to Apple is a classic example. For some, no matter how much they might want to become an Apple user, having to replace all of their applications and much of their hardware is too high a price. The change has nothing to do with a desire to use better tools, it’s a function of the practicality of such a move.

There are basically four stages that consumers go through when moving from one technology or product to another: 1. unaware of the product, 2. aware of the product, 3. desiring the product, and 4. adopting the product.

Each of those steps is exponentially, not incrementally, more challenging. Getting consumer awareness is relatively easy. All it takes is an investment in advertising. Getting people to desire your product is much more difficult. It means you have to create something more compelling then what they currently use. Adoption is harder yet, particularly if it involves a drastic change, or a significant time or financial expenditure. The upside must be so great that it overcomes all of the negatives.

That’s why it’s almost always better to be first to market than best. You can still eventually win if you’re late to the game, just like Tesla did, but it takes much more work, and your product must be that much more great.

Company Intranet

Posted by Rick Ellis on March 25, 2008

One of the byproducts of having started out as a company with one employee (me!), and allowing our growth to happen organically, is that until recently we didn’t need much in the way of employee documentation, or even internal policies and such.

Over our first five years, until 2006, we had only grown to four full-time employees including me, plus a couple part-timers. We didn’t need internal documentation for a group that small. Everyone communicated constantly.

All we had was a simple employee handbook that covered the basics, the rest we filled in by talking amongst ourselves. We discussed all important issues, and often made decisions as a group. It was a good dynamic.

From then until now we’ve more doubled our staff size, and this year we’re on pace to add three or four more team members. Unfortunately, we can no longer expect new employees to learn our process, goals, policies, history, and culture through osmosis and direct discussion anymore. As much as I enjoyed the more personal approach of the past, it doesn’t scale.

The solution we’ve decided upon is to create a staff intranet, as a series of blogs, containing everything that an employee might need to know. The book on EllisLab, if you will.

The intranet will also help us, perhaps most importantly, continue to integrate new people onto our team and into our culture. It’s critical that as we grow we continue to maintain our values, and help new employees adopt them. This is an area where so many small companies screw up as they grow.

Part of me thinks it would be interesting to make our intranet, at least in part, publicly accessible. Why not share with the world how and why we do the things we do? Why not be totally transparent? It could be a refreshing approach…

Different Viewpoints

Posted by Rick Ellis on March 25, 2008

My wife doesn’t understand computers very well, therefore she is easily annoyed by them. For her, a computer is an appliance, like a toaster, to be used for a specific task, so it should work 100% of the time.

I love and understand computers, so I tolerate their imperfections. For me, a computer is not an appliance, it is an extension of myself, so it will have quirks and imperfections.

If my wife is browsing the web and a page is slow to load, she expresses frustration. Why doesn’t it work like the telephone? You dial, it rings, the other person picks up!

If I’m browsing the web and a page is slow to load, I understand that my request must go through numerous switches and routes on its way to a server somewhere in the world. At any step of the process, or at the server itself, something might cause a slowdown.

If my wife’s computer gets sluggish, or if she sees the spinning beach ball, she curses at it.

If my computer gets sluggish, or if I see the spinning beach ball, I understand that an application has bumped into an exception, or that there are processes spawning behind the scenes, one or more of which has caused the processor to divert its attention from the task I was doing.

My wife gets annoyed that I seem so at peace with my computer, and rarely ever have trouble with it.

I get annoyed that my wife is impatient with her computer, and regularly seems to have trouble with it.

My wife’s perspective is totally valid. Her viewpoint is based on her assumptions, expectations, and experience.

My perspective is totally valid. My viewpoint is based on my assumptions, expectations, and experience.

Neither of us is wrong, we are only different.

What is it about Twitter?

Posted by Rick Ellis on March 24, 2008

I’m not sure I understand why people are so into Twitter. Every once in a while I’ll wander over and follow a thread or two written by someone I know, or know of, but within a minute or two I’ll be bored. It seems a little trite to me, like snacking all day instead of eating a good meal.

I want to like Twitter, I really do. But it seems like a waste of time to follow what dozens (or hundreds) of people are doing throughout the day. How the heck are you supposed to get anything done if you’re engaged in a never-ending conversation?

According to Robert Scoble, following people on Twitter is important because:

You’re trying to learn more.
You’re trying to meet more people.
You’re trying to be a better listener.
You’re communicating to the world that you’d like to be listened to.
You’re trying to find out about more stuff. More events. More stories.

A worthwhile list, for sure. I want all those things too… but is Twitter really going to give me all that? Seriously? Twitter?

I can see the value in using Twitter for specific things, like live-twitting an event, or even as an ad-hoc chat client for a group project. But to chronicle and follow the minutiae of people’s lives seems more like something you’d do in high school. It seems a little juvenile, frankly.

Someone needs to explain it to me, because I just don’t get it. There has to be more here then meets the eye. Is there? Maybe I’m hopelessly out of it…

The Planning Fallacy

Posted by Rick Ellis on March 23, 2008

A universal phenomenon among humans is that we are terrible at estimating how long a project will take to complete. Cognitive psychologists call this “The Planning Fallacy”, and the more complex or numerous the steps involved, the more likely that we will be wildly wrong.

The problem has to do with the way we visualize projects, focusing only on the successful steps needed to complete the task. We visualize optimistically, rarely taking into account all of the things that can, and will, cause each step of the process to slow down.

Studies have found that people almost always underestimate, even when researchers ask them for a worse-case scenario. In fact, the accuracy tends to be about the same whether we plan with great detail, or just estimate a date off the top of our head.

For those of us in creative fields, like writing software or designing websites, estimating how long a project will take is even more difficult because there is an exploratory nature to these tasks. We’re not building widgets on an assembly line, we’re working through a series of challenges.

Sure, we might know what we want to accomplish, we might even have a pretty good idea of how we intend to accomplish it, but along the way there are endless smaller challenges to solve, each overlapping in different ways, and bringing new problems, ideas, and opportunities. It’s simply impossible to envision how a project will evolve until we’re in the thick of it.

Some people have suggested rules for estimating projects, like coming up with a timeframe, then doubling it. That’s not a bad idea (especially with budgets), although it further reinforces just how terrible we are at estimating, and just how wrong we will be no matter what we say.

Why do I mention all this? To explain why we at EllisLab never publish a software release date until we are nearly finished with the project. In my experience, any date that is more then 30 days out will always be wrong.

That’s also why we don’t publish a road map that describes where we’re going with our applications. There is such a fluid and dynamic nature to technology that anything we plan for today will probably be irrelevant a year from now. We just do not have enough information today to plan correctly for tomorrow. Our development cycles, and the internet at large, are moving too fast.

I wish there were a methodology that could be used to meet goal dates with precision, but thus far, I’ve never found one. Until that day, we’ll have to stick to our policy of not disclosing released dates until we’re nearly finished with the project.

Un-Virtualizing Ourselves

Posted by Rick Ellis on March 22, 2008

Some people might find it surprising that we are a virtual company. Most everyone on our staff lives in a different city.

I didn’t plan it that way, it just happened organically, as members of our community stepped forward to fill jobs that became available. To this day we have never recruited externally. It’s been a great strategy that has allowed us to tap the best and brightest among us, even though our staff is now scattered throughout the U.S. (and one crazy guy in Canada).

For most of our history we’ve been small enough that we could collaborate efficiently via email or IM, so the physical address seemed inconsequential. As we’ve grown, however, the question of whether we should remain virtual has weighed on me.

Once a company reaches a certain size, it becomes more difficult to build, mange, and grow effective teams. I’m not sure it’s even possible to scale a tiny, connected, highly productive virtual team into a much larger company without losing many of the attributes that made the team so great in the first place.

Four years ago our entire staff consisted of Paul, Les, and Me, along with a little part-time help in our forums. Paul and I were the development department, and Les handled sales. Not a terribly complex company structure. With such a small group there was constant overlap, as each of us did whatever was needed to keep moving forward. We were agile, lean, and productive, and our communication and camaraderie were great.

Since then we’ve become several teams, with two or more people in each group. There are more roles now, more personalities, more voices, more of everything. Even though we’re still quite small, I’ve already begun seeing new challenges emerge. What worked for us when we were smaller doesn’t always scale.

The critical question for me is this: If we stay virtual as we continue to grow, will our company continue to be as good?

Will EllisLab create better products and take better care of its customers if our people never interface physically? Will we develop better camaraderie? Will our creativity and ideas be as good? Will we be as connected to one another? Will we be able to cross-polinate between teams as well? Will we solve problems more effectively? Will a virtual company fulfill its potential better then one where people work together?

I’m not sure the answer to any of these questions is yes.

Of course there are some lifestyle advantages to working from home. These certainly have value and contribute to personal fulfillment. But on net balance, do those advantages outweigh the negatives, particularly if you can build enough of an upside to having your staff in one place?

As much as I love working from home, I believe a fundamental shift in our workspace and location will be necessary before long. The challenge, of course, becomes how to make that transition. How do we un-virtualize ourselves? There are some challenges here. Fortunately, some of our staff have already made a commitment to this change, even though we haven’t decided when and how, exactly, it should happen.

Les made a great point recently. He said that all small companies, if they are to grow beyond the core founding team, must turn a corner and embrace whatever changes are necessary, even if it means a fundamental shift in how the company must operate.

He’s right.