<p><a href="http://www.joelonsoftware.com/AboutMe.html">Joel Spolsky</a> recently blogged about a <a href="http://www.joelonsoftware.com/items/2007/12/03.html">topic that I think applies</a> beautifully to small business owners:</p>
<blockquote>
<p>"You will frequently hear the claim that software engineering is facing a quality crisis of some sort. I don’t happen to agree with that claim—the computer software most people use most of the time is of ridiculously high quality compared to everything else in their lives—but that’s beside the point. This claim about the “quality crisis” leads to a lot of proposals and research about making higher quality software. And at this point, the world divides into the geeks and the suits."</p>
<p>"The geeks want to solve the problem automatically, using software. They propose things like unit tests, test driven development, automated testing, dynamic logic and other ways to “prove” that a program is bug-free."</p>
<p>"The suits aren’t really aware of the problem. They couldn’t care less if the software is buggy, as long as people are buying it."</p>
</blockquote>
<p>This geeks-vs-suits battle is played out in almost every business, big or small. The smaller the business - the more likely the debate turns into a schizophrenic dialog inside one poor guy’s head:</p>
<p>The angel on one shoulder tells him to never sell out - that craftsmanship and quality should never be sacrificed just to make a quick buck. The angel gets up on a soapbox and preaches about the evils of money-grubbing big business - how they don’t care about the customer and how their product sucks because they cut corners to save money, etc, etc…</p>
<p>Then the devil on the other shoulder reminds him that he has a mortgage payment due in two days.</p>
<p>It’s not the gap between "product quality" and "revenue" I want to talk about - I think this debate is actually pretty healthy. There is a gap far more dangerous to a small business: the gap between quality and perfection.<p />
You see, small businesses can rarely afford the luxury of perfectionism - in fact, unchecked perfectionism will usually transform your business from "small" into "small-er" or "out of". In the early days of Infusion, we had to constantly battle perfectionism. It crept in from all aspects of our business: product development, marketing, sales, accounting. These are a few of my observations:</p>
<ol>
<li>There are three situations where perfectionism hits: when you’re performing your craft (whatever it may be), any time you have to <em>write</em> something, and when you have to make a decision. Case in point: I should have been done writing this an hour ago!</li>
<li>Perfectionism working alone = bad = expensive</li>
<li>Strict deadlines and accountability combat perfectionism better than anything.</li>
<li>It is absolutely critical that you recognize the "good enough" point. Anything beyond "good enough" gets more and more expensive the more time you throw at it.</li>
<li>Don’t confuse quality with perfection. There’s a BIG difference. And don’t fight perfectionism so hard you lose quality. That’s an equally devastating mistake</li>
</ol>
<p>And if all that isn’t enough to get you to shed you perfectionist tendencies, check out a study that showed perfectionists to be more <a href="http://www.webmd.com/balance/news/20070504/why-perfectionism-isnt-perfect">"anxious, neurotic, and exhausted".</a></p>
<p>And this post is officially "good enough".</p>

Convincing your CEO to invest in large architectural “projects” (ie. refactorings, frameworks, technologies) is no easy task. CEOs usually don’t understand technology that well, and software architects usually don’t understand business that well.

Here’s a conversation between a CEO and software architect about why they should refactor their code base to use MVC.

Architect: MVC is a standard design pattern where your model is separated from your controller and view. The controller takes in an incoming request, processes some business logic, and creates a data model for the target view. Then, usually, a view dispatcher will locate the appropriate handler and dispatch the request to the appropriate view. The view them pulls from the model to render its content.

We really need a framework to help us do this.

CEO: Hmmmm…. MCV … sounds interesting.

Architect: It’s MVC.

CEO: That’s what I said… MVC. So, this “MVC” will make our product more user-friendly?

Architect: No.

CEO: Hmmm… but it will make it run faster, right?

Architect: Not really. In fact, it may run slightly slower.

CEO: Really?? Will use less ROM?

Architect. RAM. And no, it will probably use slightly more RAM, too.

CEO: So, you’re asking me to invest a bunch of money in some architecture that won’t improve the feature-set of the product, runs slower, and uses more memory?

Architect: Well, I wouldn’t put it that way…

CEO: Our VC firm isn’t going to like this. What’s wrong with the way we’re doing it now??

And therein lies the million-dollar question: What’s wrong with the way we’re doing it now? Some synonymous retorts might be: “Tons of huge software companies have crappy architecture” or “Tons of software companies with great architecture go out of business”. These are all completely justifiable responses from your CEO. Most of the time, programmers view the CEO as someone who “just doesn’t get it” or “only cares about money”. Because CEOs don’t understand the inner workings of the technology, they are typecast as not being as smart as developers. The truth is that most CEOs are much much smarter… Did you ever wonder why they make so much more money than you????

I’ll let you in on a little secret. It’s not that a CEO just cares about money. Actually, The CEO cares about whatever the shareholders care about; The shareholders are the ones that hired the CEO, after all. And they are the ones that have the power to fire the CEO as well. The CEO doesn’t answer to Slashdot, or to the W3C, or to Sun, or Microsoft, or any of those opinionated bloggers that despise smelly code. He cares about what the shareholders care about - which is almost ALWAYS money. And it’s not just money. It’s money TODAY!

So, any argument to the CEO that involves spending money should include a justification of how that money will turn into more money, and SOON.

Architect: What’s wrong with the way we’re doing it now? That’s a great question. Right now every screen you visit in our application is it’s own unique “file”. The file contains all the programming code to handle the information displayed there. Right now, we have to put some code at the top of every page to check whether the current user is logged in. It looks like this (make sure to write in VB, as VB is mind poison and will disorient your CEO):

If CurrentUser.isNotLoggedIn Then
Response.Redirect “/login_page.html”
End If

Recently our product development team asked us to implement a more robust login checking mechanism that would allow us to check a login across several machines. Unfortunately, the code we wrote above can’t do this. So, we have to go replace everywhere that has the “old” code and put in the fancy “new” code. The only problem is that the “old” code exists in 3,543 different places.

CEO: Wow, that sounds like a lot of work!

Architect: Yes, if we had MVC implemented we could make the change in approximately 1/2 hour instead of one month because MVC dictates that the login checks are all contained in place or are easily added as interceptors.

CEO: How long will it take to write up an MVC?

Architect: Probably about two months.

CEO: Hmmm… Well, we can make this one change in one month, or take twice the effort to do MVC. I think we should just make the one change. It will save 50% labor costs.

Architect: Yes, but you can only afford to make one other major change like this to break even. And with each change after that, you will be losing money and time. Also, developers hate working with unorganized code so it hurts morale. And it introduces more bugs and creates inconsistency in people’s approaches to doing things.

CEO: Wow, that makes a lot of sense.

See how I just convinced the CEO that we should implement MVC? Now, here are a couple of pitfalls I would suggest you avoid:

1. Don’t halt development for a “long time”.
How you define a long time is different for each organization. Be sensitive to this - and figure out a way to develop in parallel, even if it means more overall work. Most products, especially startup products, can’t afford to have innovation halted in favor of architecture refactoring. Sometimes it’s okay to be inefficient.

2. Don’t do too much at once.
Doing too much at once will cause developers to trip over each other, will create more bugs, and will increase the risk of the project. Longer projects mean more investment, which will make it harder to justify ROI on the project.

3. Don’t make things too perfect
There is a law of diminishing returns with refactoring projects. In an effort to “get it right this time”, avoid the urge to get it perfectly right. You can easily double the cost and size of the project while only getting 10-20% more return on your work. Think of it like buying a CPU. There’s always a big jump in price to get the cutting edge fast processor. Only idiots and freaks buy those processors. Always buy the one right below the jump.

4. Provide a short-term ROI
Again, “short-term” is up to each business. If you are a startup, don’t try to justify an ROI that’s going to happen in 10 years. Your CEO most likely cares about next month a lot more than next decade. Find and prioritize projects to give you the most short-term bang for the buck.

5. Never say this:
“In a short 3 years, we can create a framework that will not only be perfect, but it will create all new versions of the software automatically without any work. In 10 years we should see a 4000% increase in profits because of it”

You’ll probably get fired.

I came to the realization this morning that committing to a SaaS platform not only binds you to the technology, but also binds you to the business strategy and target market of the platform provider. This is a HUGE deal!

Case Study:
In 2005, I wrote an integration piece for SomePlatformProvider.com that would help small teams manage their weekly catered lunches. The first thing I did was research SomePlatformProvider.com’s customer base. What I found was that the average customer size was 50-100 employees. Because I knew I would be selling to SomePlatFormProvider customers, I thought it would be wise to tailor my offering to fit the budget and needs to companies with 50-100 employees. Doing this paid off huge for me! Soon I was the #1 provider of catered lunch tracking and making a ton of money. Everything was great. But then, my sales started dropping off. I did a little research. Most of the new companies that signed on to SomePlatformProvider’s services didn’t do catered lunches, I found!! After more research, I discovered that instead of the average company size being 50-100 employees, it was now 400-800 employees. And what I found out was that companies that big never did catered lunches - They all hired in-house chefs to cook because it was cheaper. It was only the smaller, more entrepreneurial companies that did catered lunches. Slowly my sales dropped off to the point that I had to shut down my business.

I wonder how many people who sell platform bolt-ons have really considered this. What if the target market of the host changes to something that’s not compatible with what I’m selling?

When people talk about “platform”, they usually use the word ecosystem. This is actually a really good word - because the balance is just as delicate as an environmental ecosystem. The smallest change could cause hundreds of businesses to fail!

When I was getting my feet wet in software development, I remember a recurring debate that happened between myself and my mentor. At the time, we were in the business of custom software for small businesses (for those reading - you couldn’t see it, but my neck just twitched and my eyes rolled into the back of my head). We were trying to use these small projects to build a core of reusable software that would allow us to increase profits until we could turn it into a resellable product. Yes, we were smoking crack more or less. The problem we were constantly running into was:

- If you want code to be reusable, you have to take the time to plan and code it right.
- Nobody (and especially small businesses) wants to pay you to do that.

My mentor’s argument was that I was rushing the projects and in turn creating dreaded “spaghetti code”.
My argument was that he was taking waaay to long to “do it right” and we were losing money because clients wouldn’t pay for the work.

Under these circumstances, I was the one who found success. It wasn’t because I was the better programmer, though. In fact, he had much more sophistication in his design than I did. But when it came right down to it, I was the one who could deliver a product that worked, was on time, and within budget.

We had a mantra in the early days: Customers want their software good, fast, and cheap. They can pick two of the three, but can’t have all three. And naturally, almost every small business chose fast and cheap.

Now our company is in a much different position. We have a product and our customers don’t dictate HOW we develop. We get to do that now. And preparing for the long haul, we are definitely bringing the “good” back. Now we just have to decide if we want fast or cheap to go along with our “good”.

We are in the process of working on a groovy new interface to our already sweet small business CRM product, InfusionCRM.

Our product is web-based, written in Java - and I was thinking that we should definitely check out the latest craze in the Web 2.0 world - RIA. After some googling, I found that all three of the bigs were cross-platform. So I immediately went to check out some demos. I looked at:

1. Adobe Apollo (AIR)
2. Microsoft Silverlight
3. JavaFX (Poor Sun, I don’t think they ever intended JavaFX to be on lists like this one)

What I quickly found was that (with the exception of JavaFX), what these platforms meant when they said cross-platform was Windows+MacOSX. No Linux, no legacy Mac, no Lindows (How could they leave out Lindows??!!!).

Before I get flamed — I know that Adobe is planning a Linux version, and the people over at Mono are going to port Silverlight, and I really honestly don’t care about RIA products for Linux as a user.

I’m worried about what is means for Linux developers.

Most Web-based Java developers I know (EE and SE) develop on Linux. If the RIA runtime providers aren’t providing runtimes for Linux, what can we expect for development tools? It’s too early to tell right now for sure. Providers are just now coming out with the brand-new 1.0 versions as we speak, and ultimately the market will determine how well RIA runtimes are adopted (will it really make the ubiquitous HTML+Javascript obsolete?).

I for one will be watching very closely…

There was lots of talk about platform at SaaScon 2007, starting with SalesForce’s Jim Steele revealing Apex (SalesForce’s new development platform). As part of the presentation, a SalesForce developer presented an application he’d created using SalesForce’s Apex. The application allowed for tracking time-off requests, and included a custom time-off record, workflow rules for escalation, actual code to calculate holidays and weekends, and a calendar to show the time people were taking off.

The demo was very impressive, and definitely seemed to validate the Saugatuck keynoter’s suggestion that we will see a handful of what he called SIP (SaaS Integration Platform) stacks pop up from big players. A SIP stack would provide a SaaS platform where developers could write mini-applications that would run within the vendor’s SaaS infrastructure and could extend existing functionality. Developers would be able to develop sweet little bolt-ons and not have to worry about hosting their code themselves (or creating the core functionality).
It’s interesting to contrast this idea with something like SugarCRM’s development platform. SugarCRM can also be customized, but you have to download the code and host it yourself (I’m not sure how many vendors want to run your infinite loops in their multi-tenant environment).

Either way though, it seems that these platform providers will run into a conflict of interest by providing both a platform AND functionality (think Vista/3rd party spyware). It’s already playing out. SalesForce recently purchased a Web 2.0 document management provider to be the driver behind SalesForce Content. So where does this put the 20 existing providers of document management solutions within SalesForce’s AppExchange? I spoke to one of these vendors at the event that was very frustrated with SalesForce’s new acquisition. They had spent a ton of time and money to establish themselves as a premier provider of the service within SalesForce, and now they face the prospect of being obselete within SalesForce.

It will be harder to convince development companies to jump onto a platform when there’s no security that the platform provider won’t build the exact same functionality into the core of their application later. But, on the other hand - a platform provider shouldn’t be held hostage to 3rd party apps in their developer network, as it puts them at a distinct competitive disadvantage. It just seems to me that companies like SalesForce will have an extremely difficult time balancing the relationships with 3rd party developers with the need to put the best product on the market.

On the flip-side of the equation, a platform provider that provides very little or no end-user functionality, but rather focuses on the infrastructure and platform tools will also have a hard time attracting developers because the developers don’t want to have to start from the ground up. No way the SalesForce developer is going to create a fully-integrated time tracking system in a weekend without the huge head start the core SalesForce architecture provided (Users, Permissions, Layout, etc)

So, where’s the happy medium?

The developers had our first successful trial run of a new product called callRecord from cosinity (beta). Fully integrated, it will allow us to initiate hands-free outbound dialing and call recording for our support and sales reps.

We used this amazing technology to terrorize a support rep.

http://www.cosinity.com/beta/callrecordbeta.html
User: ericm@infusionsoft.com
Pass: [standard infusion password]

Click on Prank call to Support.
Click Play.
Enjoy.

…props to Kelly for the title (I never heard the phrase before)

Towards the end of the conference, one of the moderators mentioned that he noticed a recurring theme — that SaaS vendors are moving up-market as more and more enterprises adopt SaaS. As a company that services “true” small businesses, we lend a keen ear.

Let’s assume for a moment that big players really are moving up-market. For a company that provides solutions to true small businesses, this appears to validate our market analysis that larger SaaS crm vendors (SalesForce, RightNow) have out-priced the true small businesses (relative to the feature-set they get), and the lower-end (Act!, Goldmine) don’t provide the functionality required to really automate small business. As I sat in awe of SalesForce’s beautifully branded PowerPoint presentation and the nice numbers they were flashing, a few questions came to mind:

1. Can we sustain competitive growth given the fact that our sales/support overhead is several times (proportionally) that of the big boys? (we have to sell/support 1,000 customers to equal 100 larger SalesForce clients) or is this “Death by a thousand duck bites”?

2. Does this get us to “The leading provider of active crm software for small businesses”?

I think the first question is answered by asking another question: When we say competitive growth, who are we competing against? Is it SalesForce and RightNow? or is it Act and Goldmine? Or is it another SaaS-based company out there? From everything I can tell, it’s none of the above. We appear to be the lone wolf in the land of automated crm software for true small businesses. The big boys can’t afford to come down to service true small business, and the small players can’t provide the features and SaaS platform small businesses need. For SalesForce to increase their revenues by 5% in Q3, they would have to sell around 83,000 seats PER MONTH on their current small business pricing model. I would imagine it’s the same for the other large CRM vendors. And that assumes that their current pricing structure would include the equivalent feature-set of ours (which it doesn’t come close to).

So, looking around - I don’t see another player in the true small business space that can provide the feature-set we provide for the price we provide it. Our sales guys said that we just don’t lose sales to SalesForce, RightNow, Act!, or Goldmine. We don’t really lose sales to anybody! In fact, one of the sales guys with years of experience working for a huge software company they said that our close rate on people who attended a demo is higher than anything he’s seen!

And if there’s no other competitor in our space, then instead of asking ourselves if we can sustain “competitive growth”, we should be asking ourselves how fast we can grow, and if we can sustain margins. Because if we can sustain margins - there’s are millions to be made.

And I think I answered my second question.