Home About Eric Topics SourceGear

2006-02-02 14:09:36

Yours, Mine and Ours

For the last couple of years, I have been managing my weblog with a desktop content management tool called CityDesk, made by Fog Creek Software.  This fine product has suited me very well.  Most blogs serve their content with a scripting language, dynamically generating pages from a database, with all article editing taking place in a web browser.  That approach doesn't work so well for me.  First of all, I prefer to serve my content as static HTML.  More importantly, I tend to write full-length articles, so I prefer to write my content in something stronger than an HTML textarea.

So for me, CityDesk is a good piece of software.  It has templates and a basic scripting language and a simple built-in word processor and tools to manage my links.

However, I stopped using CityDesk a couple of months ago (Sorry Joel!).  Sometime later in this article I intend to make some sort of a point, but for now I want to tell the story of the tool I now use to manage my weblog.

ESBMA

Like I said, CityDesk is great, but a few things about it kept bugging me:

So I decided to write my own content management tool.  I call it ESBMA, which stands for "Eric Sink's Blog Management App".  (The astute reader will realize now that this is not an article about how to choose cool names for products.)

 

 

ESBMA is 8,469 lines of C# code designed to manage a weblog exactly the way I want, including the following features:

For me, this is the best blogging tool in the world.

A different perspective

For anybody other than me, ESBMA is one of the worst pieces of software ever written:

So ESBMA has lots of problems, but they don't really bother me very much.  Every once in a while I fix a bug.  Mostly I just avoid them, since I know where they all are.

Actually, this is my third attempt to write my own blogging tool.  The first two attempts failed because I took the time to consider the needs of other people.  Instead of building the perfect tool just for ME, I got distracted thinking about how I could turn my blogging tool into a business venture.

This time I succeeded.  I built a blogging tool which works perfectly for me.  It won't work for anybody else.  For other people, it is not merely "user unfriendly", it is "user hostile".

My blogging tool is an example of "MeWare".

Yours, Mine and Ours

I claim here that there are three categories of software:

For completeness, I suppose I should probably mention the obvious fourth category:

Coming up with examples of NobodyWare will be left as an exercise for the reader.  :-)

Observations about ESBMA and CityDesk

As I said, ESBMA is an example of MeWare.  I wrote it "just for me".  I have no other users, therefore I have none of the challenges which arise when developing software for other people.

I consider the concept of MeWare to be somewhat new.  Simply put, MeWare happens today because today's developer tools are so amazing. I would never have written ESBMA if I had to do it in C against the Win32 API.

Software development is really expensive.  Typically, the costs of developing software are recovered by convincing lots of people to use it and collecting money from [or through] those users [directly or indirectly].  When software is developed for a single user, the opportunities to recover the development costs are dramatically reduced.

So MeWare only makes sense when the development costs are very low.  I was able to create ESBMA for myself because coding with C# and Visual Studio is an extremely productive experience.

In contrast to ESBMA, its predecessor CityDesk is an example of UsWare.  CityDesk is a shrinkwrap product of Fog Creek.  It was developed by Joel Spolsky.  He uses it to maintain his website.  Other people use it too.

To any objective eye, the difference between CityDesk and ESBMA is obvious.  CityDesk is polished and easy to use.  ESBMA is user hostile, sometimes gratuitously so.

At this point some reader who is familiar with CityDesk is screaming, "Wait!  You can't use CityDesk as an example of a good product.  CityDesk is a failed product.  Joel hasn't released a new version in 42 years and he never responds to questions about it anymore!"

OK, fine.  Joel himself seems to admit that CityDesk hasn't been the big seller he hoped it might be.  However, the success or failure of CityDesk isn't relevant to my point.

Which reminds me, I promised you I would make a point, didn't I?  OK, here it is:

 

The gap between developer and user can be enormous.
It's a canyon, and it takes serious effort to cross it.

 

If in fact CityDesk is to be considered an unsuccessful product, I claim that its failure is an issue of marketing, not an issue of product quality.  People who use CityDesk love it.  It is elegant and extremely easy to use.  I daresay it is the leading application in its market niche.  The problem is that there just aren't very many people in that niche.  In the world of content management, the war between Web-based solutions and thick clients is over -- the Web apps won.  There just aren't many people like me who want a single user desktop content management system that generates static HTML.

In other words, CityDesk did a great job crossing the canyon, only to find out that there weren't very many people standing over there.

Consider what would happen if I decided to take ESBMA up to the next level, across the canyon, from MeWare to UsWare.  I would have to make it work as well for other people as it works for me.  I would have to fix all the problems described above, plus dozens more I didn't even mention.  Off the cuff, I estimate that an UsWare version of my blogging app would be ten times more effort than the MeWare version I have now.

And of course, it would be marketing suicide, since I would be competing with the well established CityDesk for the affections of the six remaining people on earth who care about apps like this.

It's All about the Users

So let's face it -- MeWare isn't actually very interesting.  Aside from the occasional outlier like myself, nobody is developing MeWare.  All of us are developing software on behalf of other people.  Whether your software is commercial or open source, it's all about the users.

Why do we develop software for other people?  Because they need software, and they are not developing it for themselves, for only two reasons I can think of:

  1. They don't develop their own software because they simply don't know how.
  2. They don't develop their own software because they are too busy doing other things.

In either case, the users are expecting us to create software on their behalf.  They expect us to see things from their perspective, to value the things that they think are important.

This is hard.

The Challenges of ThemWare

The detachment between developer and user is greatest in the case of ThemWare.  I create software.  Somebody else uses it.  I do not. 

This creates three challenges that I want to highlight:

1.  Maybe I don't even know how to use my software.

In this situation, I work all day creating dialog boxes and toolbars, but I don't actually know what to do with them.

Several years ago I worked as a developer of data visualization tools for scientists.  Our software could take data and create pretty pictures like contour plots and line graphs and colorized grids.  I took physics and chemistry in college, but that doesn't make me a scientist.  I really never knew how to use the software I was developing.  I could tell you the arcane details of how our macro language worked, but I couldn't tell you what a Fast Fourier Transform is.  I still can't.  So I could never make our software do anything interesting, but our customers could make amazing pictures with it.

2.  Maybe I don't understand the people who use my software.

The people who use my software are not like me.  They're in another field.  I'm a software programmer, but those people were trained in auto mechanics or interior decorating or dentistry.  I don't know how they see the world.  Understanding their perspective doesn't come naturally for me at all.

I can illustrate this situation with a real-life example that I face quite regularly.  The SourceGear web site has a "store" which allows our customers to purchase licenses for our products.  This store is a piece of software, and I am the developer responsible for it.  However, I never actually use it.  Obviously I never buy a copy of my own software.  (I was tempted to once.  It was the last day of the month and our sales were about a hundred bucks shy of our monthly goal.  I was so tempted to whip out my credit card and place an order for one copy of Vault.)

Anyway, this store is ThemWare, and I don't think I understand Them.  We sell our products to developers, and I understand developers just fine.  But many companies funnel all purchasing through a department which is dedicated to that purpose.  Apparently there is some sort of impedance mismatch between me and the folks in those purchasing departments, because people keep coming to our store and buying the wrong thing.

One of our products is called SourceOffSite.  The current version is 4.1, but we do still continue to sell the 3.5 version for people who prefer not to upgrade.  (Starting with version 4.0, the SourceOffSite requires the .NET Framework, and not everybody wants to install it.)  Anyway, version 4.1 and version 3.5 require different kind of serial numbers.  When you come to our store, it's important that you buy the correct version.

So the store tries very hard explain the situation.  The information is at the top of the order form.  In red.  After you fill out the order form, you are reminded again, just to be sure.

But so far, the canyon between me and Them still looks big.  We get email basically every day from somebody who just bought SourceOffSite and then discovered that their newly purchased 4.1 serial number will not work with their 3.5 server.  It is only a slight exaggeration to say that everybody who comes to buy 3.5 licenses does it wrong.

My next version of the SourceGear store needs to have an additional verification step for people in purchasing departments who are trying to buy SourceOffSite.  When the purchaser places an order for SourceOffSite, they will see a message like this:

 

Please go ask the developer to confirm which version they want.

To prove that you actually spoke with a developer, ask them for the answer to the following question:

•         "Virtual memory" is:

1.      An upcoming technology for recording TV shows

2.      A feature of your computer

3.      A piece of jargon from Star Trek

3.  Maybe I don't even like the people who use my software.

There are six billion people on the planet.  I can't be expected to be fond of all of them.

I am one of the few software developers in central Illinois who does not work for State Farm Insurance.  State Farm is one of the largest insurance companies in the world.  Their headquarters is in Bloomington, just an hour or so down the road from us here in Champaign.

The sheer size of State Farm is simply amazing.  This company is monstrous, like the Borg from Star Trek, assimilating every IT resource in the area.  They employ thousands upon thousands of programmers, all of whom are busily working on software which will be distributed to countless insurance agent drones scattered all over the nation. 

Even though Bloomington is a small city of perhaps 100,000 people, Microsoft has an office in Bloomington because State Farm is their largest non-government customer.

I can't imagine working at State Farm.  I don't even like insurance agents.  Every day I would go to the office and build software to help insurance agents be more efficient in their ongoing efforts to annoy me. 

The temptation for sabotage would be overwhelming.

The Consequences of ThemWare

In terms of the size of the canyon, ThemWare is probably the worst possible scenario.  If I am building software that I don't use and don't know how to use for people I don't understand or even like, how good is my software going to be?

I probably see every feature in terms of how difficult it will be to implement, rather than how valuable it will be for my users.

I probably find myself wanting to label or document the features using my jargon instead of theirs.

I probably create features that are tedious or unintuitive for my users.  I can't imagine why the user interface I designed doesn't make sense to them.

ThemWare is hard.

The Challenges of UsWare

The situation with UsWare isn't quite as bad.  I create software.  Other people use it.  So do I.

Unlike the situation with ThemWare, I as a developer actually have at least one thing in common with my users:  We both use my software.  This suggests that we probably have even more things in common.  Perhaps we can even understand each other.

The Best Dogfooding Story Ever

The common expression for using your own software is "eating your own dogfood".  Sometimes this term gets verbed by simply calling it "dogfooding".

If you'll indulge me briefly, I'd like to tell you what I think is the best dogfooding story ever.  However, it's not a software story.  It's a woodworking story.

The primary machine tool in any well-equipped woodshop is a table saw.  Basically, it's a polished cast iron table with a slot through which protrudes a circular saw blade, ten inches in diameter.  Wood is cut by sliding it across the table into the spinning blade.

A table saw is an extremely dangerous tool.  My saw can cut a 2-inch thick piece of hard maple with no effort at all.  Frankly, it's a tool which should only be used by someone who is a little bit afraid of it.  It should be obvious what would happen if a finger ever came in contact with the spinning blade.  Over 3,000 people each year lose a finger in an accident with a table saw. 

A guy named Stephen Gass has come up with an amazing solution to this problem.  He is a woodworker, but he also has a PhD in physics.  His technology is called Sawstop.  It consists of two basic inventions:

The videos of this product are amazing.  Slide a piece of wood into the spinning blade, and it cuts the board just like it should.  Slide a hot dog into the spinning blade, and it stops instantly, leaving the frankfurter with nothing more than a nick.

Here's the spooky part:  Stephen Gass tested his product on his own finger!  This is a guy who really wanted to close the distance between him and his customers.  No matter how much I believed in my product, I think I would find it incredibly difficult to stick my finger in a spinning table saw blade.  Unbelievable!

Back to the problems with UsWare...

I think dogfooding is one of the most important things a developer can do.  Nothing gets you closer to the perspective of your users than becoming one of them.  But UsWare still has challenges.  Your users are still probably not exactly like you.

Recently, this very issue has been discussed with respect to Microsoft's dogfooding of Team System.  People wonder if Microsoft is going to end up creating a set of developer tools that are useful only for software companies.  This is a valid concern.  There are far more companies out there that produce software simply as a means toward producing something else, like jets or laundry detergent.  Those companies probably don't work exactly the way software companies do.

SourceGear DiffMerge

With UsWare, there is a tendency to get stuck in the following path of logic:

  1. I use the software.
  2. I understand it.
  3. So everyone else understands it too, right?

I have this problem with the SourceGear DiffMerge tool that comes bundled with Vault.  This app can be used to help perform a three-way merge.  The basic operation is fairly complex, so the tool needs to do a great job presenting a user interface which is easy to understand.  Apparently, it does not.

I helped designed the tool, so it always makes perfect sense to me.  So, when users have trouble understanding it, I have a tendency to suddenly become Basil Fawlty, the rude English hotel manager played by John Cleese:

User:  I don't get it.

Basil Fawlty:  It's perfectly simple.  There are three files being displayed on your screen and we shouldn't have to label which one is which because it seems perfectly obvious to us and so it is not the software which is defective here but rather, its user.  Thank you so much, good day.

Unfortunately, very shortly after this happened the first time, one of SourceGear's developers walked into my office:

SourceGear Developer:  Hey Eric, you know that DiffMerge tool we ship?  I don't get it.

Basil Fawlty:  Right!  Apparently I'm the one who is defective here then.  Manuel!

It is more or less impossible for me to design a user interface that I don't understand, but it is all too simple for me to design one that other people don't understand.

Rant:  Flagged messages in Mozilla Thunderbird

Another problem with UsWare is the case where I the developer design and optimize features for the way I use them, forgetting the my users might be using them differently.  For an example of this, I'm going to switch places and cite a case where I am the user.

My favorite email client is Mozilla Thunderbird.  I like it very much, except I wish that flagged messages would work the way they do in Outlook.  Every time I see a new release, I have high hopes that flagged messages will finally work the way I expect.  Last week I upgraded to the new 1.5 release, and once again, I was disappointed.  Thunderbird supports flags, but it cannot search for flagged messages or filter views with flag as one of the criteria.

Bottom line:  Thunderbird has flags, but they seem to be mostly for show.  They look nice, but they aren't very useful.

I assume that Thunderbird is UsWare.  In other words, I assume that all Thunderbird developers actually use Thunderbird as their mail client.  I am forced to conclude that the Thunderbird developers just don't use flags the way I do.

My Blindspot about Visual Studio integration with Vault

Let me tell you about another UsWare problem we've experienced at SourceGear.  First, a little background:

Oversimplifying, there are basically two ways to use a version control system.  You can use a standalone application, or, you can integrate the features directly into the Visual Studio IDE.

Here's the problem:

You see, I hate using source control integration within Visual Studio.  Our product does include this feature, but I never use it.  In fact, right now most of the people at SourceGear don't use it.  However, a clear majority of our customers do.  This little canyon causes problems.

Sometime in the last year or so, the painfully obvious truth hit me like a ton of bricks:  Our users want integration.  We have always explained things to our customers somewhat like this:

But this is exactly the opposite of what they want.  Most people don't want a standalone source control application.  Some of our customers have never even launched it.  They just want source control features to show up in all the right places in their IDE.  The key thing to notice is that IDE stands for Integrated Development Environment.

If you are reading this and wondering how I could miss something so obvious, then perhaps I have convinced you how easy it is to find a canyon between you and your users.

Here at SourceGear, most of us are software developers, and we use Visual Studio.  We build version control tools for software developers, most of whom are using Visual Studio.  Obviously, we eat our own dogfood by using our own product as our version control system for the entire team.  Nobody could possibly be more similar to their customers than we are, right?  :-)

I have known all along that most of our users want integration.  But I guess I never let it really sink in.  Sometimes my thoughts about our product strategy have been better aligned with the way I use the product, rather than with the way our customers use it.

Anyway, integration is getting a lot more air time among the developers at SourceGear.  On several occasions, we have changed our plans to allow us to give a higher priority to integration.  We are trying to cross the canyon between us and people who only use our product within Visual Studio, and other IDEs as well:

We get it.  A lot of our attention right now is being spent trying to make sure that people can enjoyably use Vault in the IDE they prefer.

And by the way, once we get the new Visual Studio integration client working, I will be using it.  :-)

Meeting these Challenges

So ThemWare is hard is because our users are nothing like us. 

And UsWare is hard because we keep assuming our users are exactly like us when they're not.

This is the point in the article when you are expecting me to suddenly reveal a pearl of great wisdom on how to solve these canyon problems.

Sorry, but our time is up.  :-)

You see, this article is the essay version of a talk I am presenting to the Jacksonville .NET User Group.  Right about now is the point where I will be out of time.  If I had left time for a really good answer to this problem then I wouldn't have had time to for my John Cleese imitation, which I can assure you was far more effective in person than it was in print.

However, although I can't offer give a good answer to this problem, I have just enough time for something flippant and trite:

Listen to your users

And be transparent.  Let yourself be accountable for listening to your users.  The main reason SourceGear did a Dreamweaver plugin is because we have a public support forum where dozens of people asked us to do one.  This is one of our most common feature requests.  How could we ignore them?

Your users have things to say.  Stop telling them how great your software is and listen to them tell you how to make it better.

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.