Tribal Pizza

Now In The Freezer Aisle

No, we aren't going to start selling frozen pizza.  Instead, we're putting Tribal into "deep freeze".  Our first shot at getting off the ground didn't pan out.  We've contacted the folks who bought Pizza Designs and the refund checks have been mailed out. 

Our sincere thanks goes out to everyone who cheered us on along the way!

Comfort != Happiness

The last couple of posts (Brussels Sprouts and Difficulty Is A Vector) might give you the impression that it's all doom and gloom at Tribal these days and that's not the case.  We're currently in The Dip, where we've made a massive push and have made serious progress,  but have hit our first real wall -- getting unit #1 open and operating. 

The gloomy posts serve two purposes. The first is to let people who are going through similar challenges know that we share their angst.  The other reason is that if we don't capture the difficult times now, we'll likely gloss over them in the future when they're behind us. 

That brings me to the title of the post.  We simply don't equate comfort with happiness.  I'm not sure when this got drilled into us, but I think it really gelled during our "big company" days.  All too often, we saw folks choose the path of comfort and with pretty dismal results.  Opportunities were missed, implementations were mediocre, and innovation withered all because someone (or several someones) in the dependency graph decided that they didn't want to be uncomfortable.

So, the forecast for the next few weeks is lower lows, with a chance of higher highs and gusting difficulties in the direction of our choosing.

"Difficulty" Is A Vector

Webb and I were talking about some options with Tribal's first delivery unit.  As with any set of options, each one had it's pros and cons.  A couple of the options represented several miserable months while we got our systems, schedule, and staff put into place.

These were still considered viable options and he hit the nail on the head when he said, "It doesn't suck any more than walking into a cushy job and losing a little piece of your soul each day . . . it's just different."

Thus was born the Tribal Pizza Unified Theory of Suckitude, which states: "Sometimes you control the magnitude of the suckiness, sometimes you control the direction, you may even be able to exchange control of one for the other.  Good luck trying to control both."

The next time you find yourself in a difficult situation, ask yourself: "Am I here because I chose the magnitude or the direction?"  If you chose the direction, then it's your own fault that it sucks so much.  If you chose the magnitude, then it's your fault for being there in the first place.  And what if you chose neither?  Then it's your fault for treating difficulty as point with neither direction nor magnitude in an attempt to violate the laws of nature.

Brussels Sprouts

I'm pretty open about food and as I have aged I have become more accepting to different tastes. However, one thing that has never changed is that I can't stand Brussels Sprouts. As a kid, I tried three strategies for dealing with forced consumption of the horrid little buggers.

First, I railed, threw a fit and refused to eat them. That didn't work!

Second, I swallowed them whole and forced them down with water. Well, I didn't have to taste them, but, almost choked. Plus the darn texture bothered me more that way.

Lastly, I accepted my fate and decided to eat them first. I knew I wouldn't like it, but, I would eat them first and get them out of the way. Then I could cleanse my pallet with my other food and enjoy my meal -- sprout free.

When my task list becomes filled (as often it does), I am reminded to eat my Brussels Sprouts first (in other words the most despised tasks get done first). This leaves my remaining work to cleanse my pallet and refresh my soul.

How do you deal with despised tasks?

Meatball Sundae or Tomato Basil Goodness?

Today, Seth Godin talked about his new book Meatball Sundae. He published a thought piece from the book describing what a Meatball Sundae is. In particular, he was describing it in terms of Web 2.0. You know: social networks, user generated content, viral marketing, and AJAXy goodness! The analogy is relevant to many market trends though. It’s the idea that you can simply have a better business by tacking on whatever the latest trend is. Currently that is Web 2.0. 

This made me think about our approach to Tribal Pizza. The core idea behind Tribal Pizza breaks down into three parts: 

• Tight logistical management of the supply chain. (Whew! Jargon overload)
• A unique (for now) user experience, ala user participation via Pizza Design and Pizza Battle. Add to that order tracking.
• An in your face attitude, all the way from the Web Site, to our approach to marketing. We are different, not trying to be different! 

I weighed each of these prongs against the Meatball Sundae analogy. Here are some conclusions: 

• Tight logistical management is critical to the operation. This is not Marketechure. Tightly controlling the bottom line allows us to compete in a market where food and gas prices will continue to increase in the future. This key enabling technology will allow us to run harder and faster than our competition. Period!
• The user experience is highly influenced by Web 2.0 trends. Jay and I have always felt that brining our customers into the experience and actually making them part of the company is part of our not so secret Juju. We want our customers to feel like they own part of Tribal Pizza and our success can be theirs as well. Further, we think once we are up and running this is going to be a big part of driving our word of mouth marketing. “Dude, I kicked Johnny’s butt in a Pizza Battle yesterday! I took his money and his design.” “Really, that sounds cool, what’s a Pizza Battle?”
• Our attitude at the surface seems to be very Web 2.0’ish. Not really. This is just our combined personality manifested in a corporate entity. Jay and I have really tried to build the company that reflects us. Behind the visions of sugar plums dancing in our heads, the real motivation is to  build our company. You can see it in everything. From the vague references to Snowcrash to the deep red tomato colored website. Tribal Pizza is us! 

I like the analogy Seth uses. Going forward I think it’s a salient mental picture for us to weigh some of our approaches against. Does this make the sundae taste better or are we just placing meatballs on top? 

What’s your experience with Meatball Sundaes and the high priests of what is cool today?

Minimizing Procrastination or the Careful Art of Negotiating with a Rogue State!

I've been thinking about procrastination quite a bit since starting my own company. There is an entire industry promoting helpful tips on how to avoid procrastination. I've never really spent much time until recently reading any of the advice. Instead, in the past I just tried to avoid procrastination. My success rate is hit and miss. Some careful analysis of my own love/hate relationship with procrastination has led me to some interesting conclusions. First, if you are like me -- you just can't avoid procrastination. It's just part of your character. I know I like to work in spurts. Do nothing. Pulse. Do nothing. Do nothing. Do nothing. Pulse. Well, this pulsing strategy works really well for some types of adventures. Some it doesn't. It's not conducive to owning your own business -- there are just too many plates to spin. Something always needs your attention. So if we can't avoid procrastination, how can we minimize it? How can we negotiate with it?

First, see procrastination as a strategy or a technique for achieving a host of different goals. I've begun to see procrastination as a form of asymmetrical warfare a part of my psyche uses against the more successful, driven and motivated portion of my psyche. But why? Well, I would categorize the goals behind procrastination this way:

• Delaying a potential frustrating, embarrassing, or difficult event
• Using my time in an alternative time-wasting manner, such as daydreaming
• Avoiding a boring or uninteresting task
• Being lazy because I'm either mentally or physically exhausted
• Being lazy because I believe I'm either mentally or physically exhausted

The little rogue state that encourages the use of procrastination isn't such a boogie man -- just misunderstood and underrepresented. Also, he's not that mature; so he doesn't use good techniques in dealing with situations. Armed with this information, I've come up with some alternative negotiating strategies for dealing with him. Yes, I negotiate with myself! I'm not that concerned with my sanity because they are bilateral talks -- if they were six party talks, well then I'd be riding the crazy train.

Here's a few different negotiation strategies, they go something like this:

Scenario 1:

"OK, so I see you want to procrastinate. Why?"

"Well there is some unpleasant event I don't want to deal with."

"OK, let's take care of that right away! Now!"

"Now."

"Absolutely, the sooner the better. That way there is no time to worry about it. The more you worry the more dreadful it seems."

"I don't want to."

"I know, guess what, let's use that time we free up from worrying to do something fun."

"Fun?"

"Oh yeah, let's daydream, read a book, walk in the park, grab a beer, or catch a movie."

"Really? Can we get a beer and see a movie?"

"Sure. But, first we deal with the event."

"OK!"

Scenario 2:

"Hey, do we have to do such and such? Let's do nothing instead!"

"Why don't you want to do such and such?"

"It's boring!"

"Yeah, I know"

"Cool. Agreed? We can do nothing then?"

"Hold on. We really need to get this done. Here are the consequences of not getting this done. Guess what, it may actually mean we have to work harder."

"So. But, not right now."

"I hear ya. Guess what, I'll make you a deal. Let's work on it for 40 minutes and then we can take a little 20 minute screw off break. What do you think?"

"I don't know."

"Come on."

"OK, but, just this time."

At this point, I think to myself, no problem I can negotiate with you all day like this. We'll get 8 or 9 hours of work done at this pace.

Anyways, you get the point. When you find yourself trying to procrastinate find out why. Then try to negotiate with the part of you that wants to. Trade with that part of yourself if you have to. Sometimes, when you've driven procrastination a way for a while let him win a few negotiations. Just don't let him in on the secret that you have only let him win the battles you wanted to loose. You're consciously creating free time for your mind and body to relax and have fun -- and that is doing something! That helps you drive your success and stay motivated.

How do you deal with procrastination?

How do we secure your password you ask?

Actually, you didn't ask. But, we think you should have. Better yet, we think you shouldn't have to. Expect this information to migrate on to the main site. We feel as a holder of your account and personal information we have a responsibility to inform you on how we manage your password and personal information. We feel every website you interact with should do the same.

Found a fairly timely post on digg this morning regarding this topic -- You're Probably Storing Passwords Incorrectly. It's timely because I was planning on writing about this topic today. Glad to see other people are concerned about this. This is an interesting topic; most websites (even several of the more famous) do this wrong). Jay and I put a bit of thought into this upfront. We made a few conscious decisions regarding management of passwords and personal information we thought was best for the consumer. Namely:

1. We would not store passwords. Rather, we would store salted hashes. This brings up one minor inconvenience -- if you loose your password we generate you a new random one. We CANNOT recover your password. At the same time, outside of a brute force attack neither can someone who snags our customer database. We use a SHA-512 HASH along with a randomly generated 8 byte salt for each password stored. One thing we could improve is increasing the size of the salt.
   
2. We would not have a pre-canned set of security questions for password reminders or reset. We can't recover your password anyways. Instead we provide you a reminder -- you can put what you want there. Doesn't matter to us. Lot's of folks put a hint or the word 'standard' to indicate this is the one they normally use. One thing we feel strongly about is canned questions are inherently insecure and a reminder can be secure if you choose it to be.
3. We did not want to put password strength checks into the password requirements. Oh no! You guys don't care about my security! Actually, we do. Those that use good strong passwords will continue to use good strong passwords. Those that don't wont. Rather than force you to conform to a set of rules we think is good we let you choose. I think it is arrogant to assume someone who can't remember a complicated password will if you force them to for their own good. They will simply write it down somewhere! Now what did you achieve? This one is near and dear to my heart. I used to work as a sysadmin for the University of North Texas. I worked for this great old tinkerer named Jerry. Jerry maintained the servers and the computers for the Department of Engineering. One day I got the bright idea to put in a more secure admin password. Shortly I realized my mistake. Jerry was a smart guy, but, older and just couldn't remember the password I created so he wrote it down on a sticky. All I did was lower the security of the system!
4. When we start accepting orders we are going to provide you the option of storing your credit card information for quick checkout. When we do this, we will encrypt the information using your password to synthesize a key. This means that we will ask you for your password one more time before processing a speed order -- remember we don't have it! If our database is stolen then each credit card number stored must be brute forced. The difficulty of this act will depend on each user's password. Yes, this means if you reset your password we will discard the encrypted credit card information because it can no longer be recovered.

One weakness in our current system is that during password reset your new password is sent to your email. As we all know, depending on the route from us to your inbox that email may be read by snoopers along the way. There aren't many great solutions to this problem that do not incur lots of verification headaches for you and us. Again, we don't feel too terrible about this because if you did store any super sensitive information with us, it would have been destroyed by the password recovery. This is an area we will continue to think about and refine. Any suggestions out there are welcome.

We feel these choices provide a good compromise between securing your personal data and providing a good customer experience. We also feel that websites should be more forthcoming in how the manage and secure your accounts and personal information. Hiding this information only helps attacker and would be malfeasants.

What do you think of our choices?

Dealing With The Database - The Great Impedance Mismatch (Part I)

First, a minor confession, I dislike loathe databases. The only thing I may loathe more are the self-appointed high-priests of databases, DBA's. However, They are a necessary evil. Invariably, most software solutions need one, so I begrudgingly accept its role. My major complaint is that the industrial solutions that exist today are all some form of Relational Database Management System (RDMS). Working with them always is a hassle. The software I write has nice little object abstractions for the entities I deal with it – it's great. I don’t worry much about how they do what they do – they just do it. That is until I must bridge the great impedance mismatch to get them in and out of the RDMS.

There are many solutions to this problem – most of which I am continually disappointed with. There are several Object-To-Relational Mapping (ORM) solutions out there; most of which I despise. Why? Well, they ask me to know too much about the database (remember I loathe them???). I don’t want to design stored procedures, I don’t want to design tables, and I don’t want to map the two. I want to build objects! 

Why must I: 

• Maintain data layout information in two places?
• Know some less than conformant version of SQL syntax?
• Deal with a mess of SQL scripts as I adjust the definition of objects over time?

In my previous commercial existence, I and some very talented folks have waded right into this problem. The first time we tackled the problem, it was to provide an RDMS like view of network data. As things went forward, we realized we wanted to address this problem in such away as the backing store did not matter. In other words, the objects we requested information from could be backed up by a database, network calls, excel spreadsheets, etc. You get the idea! 

Before you all start posting comments, yes I have heard of ODBC, ADO.NET, WMI, CSLA, and Hibernate. Hold your horses. Each of these doesn’t really help solve the problem I want solved. I DON”T WANT TO DEAL WITH THE DATABASE. 

Further, when querying I am a huge fan of Query by Example (QBE). Let me show you an object and you give me back a list of them that look like it.

Here is how this works (lights, camera, pseudo-code): 

Formula exemplar = new Formula();

IStore store = ServiceFactory.Instance.Retrieve<IStore,Formula>();

exemplar.Email = ‘mwebb@tribalpizza.com’; 

Console.WriteLine (“My formulas”); 

foreach (Formula f in store.Retrieve (exemplar))
{

Console.WriteLine (f.Display);
}

Yes, this is how our current system works. Short, sweet, and to the point. 

In dealing with this problem, I want to work with three real abstractions: 

• An entity
• An entity’s definition
• A store

An entity is just that -- well let’s say something like a Pizza Formula. I want to describe its properties, their constraints, relevant data-types, and be done. We’ll call this description an entity’s definition. 

A store is a place to store and retrieve entities from.

Here is how I want life to work: 

1. I describe an entity declaratively
2. A code generator creates me a magic wrapper for ease of dealing with the entity. This is not entirely necessary but damn handy. The system needs to be able to retrieve and operate on entities for which these wrappers don’t exist though!
3. A store is selected based on an implementation of the service factory and the type of identity. This gives me great flexibility in changing out backing store as well as potentially selecting the type (and characteristics) of the backing store based on entity.
4. A store must be able to read an entities’ definition and create the necessary backing store for the entity. Period! I don’t want to help it. Read the definition and create the store. I’m not creating your SQL scripts, got it.
5. A store must be able to read an entity’s definition and realize that a newer description exists. The store must be able to take reasonable actions to upgrade the backing store to realize these changes. When I say reasonable, I say the store should be smart enough to handle the additions of columns. Changing the data-type and/or deleting of columns may be beyond the capability of the store. I generally try to avoid these operations anyways.
6. A store must be able to perform relevant read, delete, and update operations.
7. I want to be able to access existing data without having the original data definitions. How? Well, easy, the backing store is also responsible for keeping track of the data definitions used to create objects. Wow! This has huge implications. More to come on this in the future. 

Now, I know I loose some things: 

1. I may not be able to eeck out every micro-second of performance that a perfectly tuned SQL script could offer. However, I intend to deal with this problem another way. The selection of which store to use is done by requesting a store from a service factory based on entity. This allows me to *tune* up specialized stores for performance critical entities that have special characteristics. I shouldn’t need to do this much, but, I have a back door if needed.
2. I am accepting some amount of lowest common denominator in backing store capabilities. Again, if this is a challenge see my solution to the problem above. 

I’ve made some pretty good progress on a solution that works for us. This is the first part in my series of explaining the design philosophy and its inner workings. Eventually, we will be sharing an open source solution to this problem. 

What are your thoughts on the great impedance mismatch and my approach to the problem?

Fun With Animoto

Sometimes you want to tell a story.  Sometimes you want to tell a poetry-slam haiku in video form -- that's what Animoto (http://www.animoto.com) let's you do.  Upload some photos, upload some music, and drop it into their rendering queue.  Not happy with version 1.0?  Hit remix and watch again.  These are some photos -- courtesy of Ecor Rouge Photography (http://www.ecorrouge.com/photography) -- taken in our warehouse a couple of weeks ago.

If you don't see the video, click through to this post.

Higher Highs, Lower Lows

I read a lot about startups.  Blogs, books, magazines, pretty much anything I can get my hands on.  A lot of people talk about "the roller coaster ride" of starting a company, which seems like a great analogy until you actually do it.

Sure, there are lots of ups and downs.  There's definitely excitement.  Certainly an admission fee must be paid.  Sounds just like a roller coaster, right?  If this were the case then any adrenaline junkie with the cost of the ticket in his pocket would jump right in.

Here's the problem: the "lows" aren't the dips in the ride.  The dips in the ride are simply part of the excitement -- they're fun, they add to the experience.  The real lows are the wait in line between rides.  You need to not only crave the ride, you have to be able to stick it out to get on in the first place. 

Most of what I read hints at the wait in line, but no one ever seems to capture it fully, probably because by the time they write about their experience they've forgotten just how bad the line can be.  So, here's my addition to the analogy to try to give you an idea of how low the lows can go:  Sometimes while waiting in line, you'll be set on fire.  That's right, actually engulfed in flames.  The rules are simple: if you wait it out and make it to the front of the line, all of the physical damage will disappear and you get to ride.  If you step out of line, the flames go out, but the damage remains.  You are informed of this rule not at the beginning of your wait, but right about the time you can see the boarding area.  You will have just enough time to say, "You must be fuh" before the match is struck and the heat is on.

There are two questions, then: Do you ever even consider getting on the ride?  After having not only shuffled along in line but having done so while on fire, do you get back in line to ride again?  If the answer to either of these is no, then you're probably best off just grabbing a funnel cake and watching the show.