Home About Eric Topics SourceGear

2004-02-23 16:55:46

Be Careful where you Build

Summary: Eric talks about the business implications that come into play when we choose languages and components.

If your parents hauled you to Sunday school every week like mine did, perhaps the following lyrics sound familiar?

The foolish man built his house upon the sand
And the rains came tumbling down

For those of you who were deprived of this early childhood ritual, allow me to provide a bit of background. The song tells the tale of two men. The so-called "wise man" built his house on some sort of a rock, evidently a first-century precursor to modern concrete. Meanwhile, the "foolish man" was constructing his home on a foundation of sand. The song ends with each of these guys getting the results any grown-up would expect them to get. After all, if you're going to put your building on a bunch of sand, you should expect it to float away when the rains come.

Unfortunately, the corresponding decisions for a small ISV are usually far less obvious. When we build our applications, we have to decide what foundation (or platform) to use, and those decisions are not at all simple. In fact, these technology choices can be so difficult that you don't have to be "foolish" to earn bad results. Many a wise man has watched his software product floating away in the floodwaters after a big rain.

What Is a "Platform"?

Metaphors from the construction industry usually work quite well for software. Every application needs to be built on a strong foundation, or "platform". Just as with a physical building, the quality of the foundation is incredibly important. If you get to the point where you regret your platform choice, it can be really painful and expensive to fix it.

For the purpose of this article, I will define the word "platform" to include everything on which your software is built. In other words, your application's platform consists of everything on which it is dependent. The following kinds of things are included in my definition of a platform:

For example, my company sells a product called SourceOffSite that is an add-on for Visual SourceSafe. Prior to our 4.0 release, the server side of this product was written in Visual J++. Therefore, the platform for the SourceOffSite server contained the following things:

I use this particular example because our application ended up "floating away", at least temporarily. The Microsoft Java VM is not officially supported on Windows Server 2003. We ended up porting that server to C# in order to offer our customers a migration path.

The Pros and Cons of Large Platforms

An important issue in platform decisions is the matter of how "large" your platform is. How much stuff do you have available for the purpose of building your application? How much stuff does your application depend upon in order to function?

Larger platforms can lead to shorter development cycles. The more the platform provides, the less code you have to write. All else equal, most software should be built on the largest platform available. However, all else is not equal. There are trade-offs to be considered. The benefit of rapid development often comes with other problems.

Problem: Performance

Code that was written more quickly runs more slowly. (For now, I'll leave this sweeping generalization undefended, but I admit that there are exceptions to the rule.)

Problem: Integration testing

Projects built on larger platforms often slow down considerably when integration testing begins. Your entire product has to pass quality assurance (QA), not just the code you wrote. When you choose a technology to be part of your platform, you are choosing to test that technology and find ways to deal with its bugs.

Problem: Nightmare install

In order to run your application, every piece of your platform has to somehow get installed on the user's computer. Either it was already there, or you have to install it. If your platform is large, installing all your app's dependencies can be quite a mess. Users get scared by complicated installs.

Problem: The user's dog is barking at your app

Some large platforms achieve development speed by doing things in ways that don't quite fit with the ways things are usually done.

For example, GUI apps written with Java and Swing do not use the operating system's native user interface (UI) controls. On Windows, a button in a Swing dialog box is not the same as the one in a regular Win32 application. It looks awfully similar, but it's not the same. Sometimes the imitation is so good that your user is not consciously aware of the problem. However, the user's dog is not fooled and will bark at these buttons, because they're just not quite right.

How Are Platform Decisions Made?

The latent trade-offs in these platform decisions are tricky. It's worth some time to look carefully at the way we approach these decisions.

By definition, choosing a platform involves a bunch of technology choices. Most organizations therefore delegate these choices to their technology people. This approach is not entirely incorrect, but it often results in major problems.

The truth is that these technology decisions have major business implications. You can't win by choosing the right platform, but you can lose by choosing the wrong one.

Do we really want some dork with a compiler making decisions that could affect our sales? Probably not.
Perhaps we should go to the other extreme and have all platform decisions dictated by management? This approach looks even worse.
Do we really want some dork with a spreadsheet deciding between wxWindows and Qt? Probably not.

The important point here is that this cannot be an "either/or" choice. When making platform decisions, you must not choose between "business clue" and "technical clue". Get both.

A Word to the Business People

Please stop reading. The rest of this article is for the geeks. You are dismissed.

Oh, and by the way, I apologize for the "dork" remark. Nothing personal. :-)

OK, Now a Word to the Geeks

I asked the business folks to leave the room because the solution to this problem begins with us, the geeks. We are the ones who understand the technology side. The reality is that these technology choices cannot be made without our help. Furthermore, we can probably learn a thing or two about business a lot faster than the business guys can learn how to find a memory leak or dereference a pointer. Let's agree not to get uppity about this. The goal here is to learn how to bring our technology expertise into platform decisions as effectively as we can.

As it turns out, this is going to be rather simple. In fact, if we're going to participate in platform decisions as geeks with a touch of business clue, there is only one concept we have to learn:

It's all about the user.

As geeks, our natural tendency is to focus on the ways in which a technology decision will affect us:

We also sometimes base our technology decisions on our own "religious" preferences:

Some of our so-called "religious preferences" are rooted in valid concerns, but we must hold them in the proper balance against considerations that affect the user. Basically, this whole point can be summarized with Eric's First Law of Platform Decisions for Small ISVs:

As developers in a small ISV,
our productivity is important,
but it must be secondary to
the comfort and preferences of
our users.

This rule will invite all kinds of criticism; so let me clarify two things:

Adopting this posture can be very difficult, but in a small ISV, it is absolutely necessary. When we make technology decisions that are good for ourselves and bad for the user, we walk a well-worn path to business failure.

The user is king. He gets to choose whether he wants to buy our application or not. If he chooses not to buy, our business will fail. Unlike us geeks, the user is a normal person. He expects everything to Just Work. The slightest hassle will often scare him away.

Let's talk about some specific platform decisions that many small ISVs are facing.

The Operating System

At the risk of being absurdly obvious, let's acknowledge that there are an awful lot of people who use Windows. And who can blame them? I certainly find Windows to be quite satisfactory. In fact, once I get emacs and cygwin installed, Windows XP is probably the nicest OS I have ever used. :-)

Seriously, basically every small ISV needs to support Windows. It is somewhat more likely that you can ignore the other desktop platforms, although we should take a moment or two and talk through this issue.

MacOS

Although my usual machine is a Windows box, I am writing this article on a Mac. MacOS X is somewhat like the Grand Canyon. It's unbelievably beautiful, and it's very hard to describe to somebody who has never seen it. Neither words nor screen shots really do it justice.

Most small ISVs don't support the Mac because "the market is too small". However, this is clearly not true for all application categories. At the recent MacWorld Expo, Steve Jobs claimed that there are around 9 million Macintosh users. If your small ISV can sell something to 1% of those users every year, you can afford to drive a very nice car. Granted, capturing revenue from that 1% is definitely not going to be easy. All I'm saying is that the Mac market is bigger than most software developers think.

Just make sure of one thing: If you're going to sell applications for the Mac, make sure your application is really pretty, or else your user's dog will be barking.

Linux

Let me start right up front by saying that I like Linux. I've been a Linux user for about ten years now. My personal Web server is a Debian box.

But Linux is still a lousy market for most small ISVs, especially for desktop applications. IBM can make money with a Linux strategy, but that doesn't mean you can.

The same basic arithmetic applies here just as it did for MacOS above. There are lots of Linux users. If you could sell something to 1% of Linux users, you could make very nice money. But capturing revenue from that 1% is going to be insanely difficult. After all, one of the distinguishing characteristics of this crowd is their tendency to use things that have zero cost. If you are one of the people who can, please accept my congratulations.

.NET Yet?

Here is one of the toughest questions for a small ISV today:

Should we be using the .NET Framework or not?

Like I said, this one is tough.

Believe me, I understand the allure. You want to use C#. You really do. It's a very nice platform for the developer. Coding is fun again. I can get stuff done really quickly in C#, and the resulting app performs and looks like it was done in good old C++.

But depending on your circumstances, your users may end up paying the price for your increased productivity. Remember, you are a small ISV. You don't have a distribution channel. You don't have the clout to get your boxed CD on the shelf at Best Buy or Wal-Mart. People are going to download your demo and make a decision that determines the success of your company. You need your download to be quick and your install to be utterly painless. If not, a prospective customer will lose interest very quickly. The simple truth is that for some users, the .NET common language runtime (CLR) adds too many megabytes to your download and another scary step to your install.

When it comes right down to it, we may need to admit that we want to use the .NET Framework for ourselves, not for our users.

#ifdef do_as_I_say_not_as_I_do

OK, fine--call me a hypocrite. Yes, I admit that we built SourceGear Vault entirely in C#. Furthermore, the complete platform for the Vault server is pretty darn large. In addition to the .NET CLR, our users have to set up IIS and SQL Server as well. All this stuff allowed us to develop Vault very quickly, but our install procedure is a lot more complicated than I wish it were. Why don't I heed my own advice?

The developer tools market is a fantasyland that is loaded with exceptions to the usual rules. Our customers are not normal people. By and large, they are geeks like us. They are far more likely than normal people to already have the .NET CLR installed.

We still want our installer to be as painless as possible, but the truth is that our users will put up with more hassle because they have more expertise and because they are accustomed to it. Like I said, most of them have already installed Visual Studio .NET, which is around three hours of their life they will never get back. The first time I installed Visual Studio .NET was in my hotel room at the Microsoft Professional Developers Conference in October 2003. While the installation was running, I watched The Legend of Bagger Vance, in its entirety. If people will put up with that, then the Vault installation suddenly looks quite painless, by comparison.

Restating this point with a metaphor from grade school: When it comes to product usability, it's okay to grade yourself on the curve.

Restating this point with an old joke: If you and a friend encounter a mountain lion in the woods, you don't have to outrun the lion--you only have to outrun your friend. :-)

#endif

Remember, "It's all about the user". If your users are normal people, you have to think carefully about whether they are ready to download and install the .NET CLR. Normal people expect everything to Just Work. When something doesn't work, they don't have the skills to look under the hood and fix the problem.

The latest toolset from Microsoft is incredibly cool. Someday, the .NET Framework will be preinstalled on every PC. On that day, Windows Forms applications will Just Work, with no user hassle at all. If you are not using .NET by then, you will be hopelessly behind the times.

But today, you have to think about trade-offs. Not every small ISV needs to be on the .NET Framework right now. For some small ISVs, it just isn't time yet, and the decision depends a lot on your circumstances. Using the proven technology from the previous wave is not as shameful as you might think--especially if that's what is best for your users.

If I were starting a product today for normal people, I would force myself to at least consider building it on the solid rock of C++ and MFC, especially if I were planning to ship the product sometime this year. I really like Visual Studio .NET, but the stuff from the Microsoft's previous wave still works, too.

The Bottom Line

Let's close this piece by returning from the specific back to the general. We can agree or disagree about the trade-offs for specific technologies, but my main point remains: It's all about the user. Regardless of whether we end up choosing large platforms or small ones, if we make that choice without giving consideration to the user, it is very likely we are making a mistake.

 

Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois. Please stop by the SourceGear booth at Tech-Ed in May so he can gloat over the fact that he gets to use C# and you don't. Eric's weblog is at https://ericsink.com/.

This article originally appeared on the MSDN website.

Copyright 2001-2023 Eric Sink. All Rights Reserved

If you are in need of contract software development services, I would appreciate your consideration of SourceGear.