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.

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!

- 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”.

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…

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?

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.

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.