Furry Moon Creations

We've returned from Midwest Furfest. It was a successful trip, with many new contacts made and many people finding out about Furry Moon Creations and our plans. Unfortunately, we ran into an all-too-common problem at the convention: illness! We've been down with nasty colds for almost two weeks now.

This leads me to thinking. How can we prevent the spread of "colds" in our products? Software can be thought of as a lot of small, interlocking pieces. How can we keep problems in one component from affecting others?

Colds spread because of intimacy. People being too close, breathing the same air, touching the same surfaces. A good way to reduce the spread of a cold is to reduce contact: wearing a mask or gloves, not coughing on others, not shaking hands. Even better, just stay away physically.

This idea can be implemented metaphorically in software design. One of the biggest problems with software security is pieces of a system being too intimate with other pieces of the system. This can be seen in modules that share the same memory space or use the same files for communication. A good way to reduce the spread of a problem -- whether a virus or some other sort of bug -- is to separate the components. We've already discussed using a messaging base in our previous post on scalability, but that infrastructure also imposes a separation between components that reduces their ability to "infect" each other with flawed or malicious content. If a component only responds to strictly defined messages, then an error or a virus in another component will be much more limited in its potential to spread harm to it.

Of course, all of this demands a certain degree of overhead. Passing messages is less efficient than simply modifying shared memory directly. We are researching platforms for implementing the message-passing infrastructure in terms of efficiency and scalability, while simultaneously designing our message system to balance the need for speed against the need for security. This often boils down to the size of the message; the finer-grained the action in a message, the more it can be separated from other actions, but the more messages will be needed to perform some actions. We expect the messaging to be adjusted as design and development progresses, but we are starting out with that in mind so we are keeping the messaging structure flexible rather than rigid and brittle to facilitate evolution in our products.

I'll be posting more details on our approach to scalability, security, and efficiency as our projects progress. I hope you will follow along with us, ask questions, and speak your mind. We don't want our development process hidden away from view. After all, that's not healthy!

I am currently attending Midwest Furfest 2009 outside Chicago, Illinois. This is the 10th anniversary of the convention, and it has grown immensely over the decade of its existence. The initial attendance figures reported by the time of opening ceremonies this year was 1500 furs, and more were arriving.  The convention is in the Westin Hotel this year, the much larger venue it moved into last year.

This move is a result of the convention's success. But such a shift is only possible due to scaling. The events must be broken down finely enough to be spread out over many rooms, and the responsibilities must be equally broken down so that additional staff can be brought in to cover gaps that appear. A convention that leans too heavily on a few individuals will not be able to grow beyond the ability of those people to manage it.

So, too, does a software project progress. Most projects begin small, with little thought to large-scale applications. Software developers have an itch to scratch, so they produce a working program as quickly as they can. This is fine if you are developing a small recipe holder or a package to annotate the few hundred photos you have scattered on your hard drive, but what happens when you decide to release it to the outside world? People have more data than you do, or they have wider requirements than you do. Your little program is strained under the pressure, but it is so difficult to expand it. It wasn't designed to take advantage of multi-core processors, and adding new UI features requires many scattered changes to your hardcoded implementation.

We are striving to avoid this scenario at Furry Moon Creations. We know, right now, that we want our products to be useable by tens, even hundreds, of thousands of people in time. We know we will be adding new content and new hardware to our systems as we grow. And we know that we will have bugs, so we need to limit them to as small a scope as possible.

This all requires us to build a scalable infrastructure from the start. Before a single line of application code is written, we will have developed a software messaging base that allows our highly compartmentalized components to talk to each other transparently, either on the same machine or on the other side of the continent, allowing both long-term expansion and reducing the possibility of single points of failure. To do this, we are pulling together both old, reliable technologies and new upstarts in an effort to optimize each segment of our underlying core.

This isn't sexy work, but it's a necessary step in making a product that can grow both with us and with you.