Home About Eric Topics SourceGear

2005-04-06 14:59:57

Geeks Rule and MBAs Drool

Summary: Eric explains the importance of "deep technology clue" for non-coders in a small ISV.

I just finished making a really difficult technology decision and I want to tell you the story of what happened. I apologize in advance for all the gory technology details—I promise that I do have a point to make after I'm done telling my story.

The Tale of a Technology Decision

I really want an Eclipse plug-in for Vault. For several months I have been trying to figure out the best way to get one.

Our product is and will remain largely focused on the Visual Studio user, but more and more people are asking us to let them use Vault from within Eclipse. Developing a Vault client for Eclipse would allow us to connect with a lot of developers that we currently cannot reach, on multiple platforms.

However, we have a portability problem. Vault is built entirely in C#. We don't regret this, but it's not exactly the smoothest path to a cross-platform strategy. We chose C# to give us other benefits, consciously accepting the tradeoffs. Vault is a Windows-centric product. If our highest priority for Vault were support for multiple platforms, we would have built our product with different technologies. But we didn't, so now our cross-platform challenges are a bit trickier.

Defining the boundaries of the problem

We fully expect that we have to rewrite the UI code for our Eclipse client. That's okay. We don't expect our UI code to be portable. But it would be really nice if we didn't have to maintain two copies of our core client library. This library is called VaultClientOperationsLib, but we usually just call it "OpsLib" for short. It is the library upon which all five of our Vault client applications are built. In principle, this 48,000 lines of code should be reasonably portable. It does a lot of file I/O, some threading and some networking. Nothing here really needs to be platform-specific.

The first thing we did was to consider and reject three possibilities that we deem to be unattractive:

If this library had been written in C++, then all of the cross-platform issues would be more straightforward. Tedious, but straightforward.
But we're simply not willing to do this. Rewriting OpsLib would require a lot of effort and risk, while providing no value for our current user base, all of whom are happy using the product on Windows.
We could probably port OpsLib to Java in a month or two.
But we're not willing to do this either. Maintaining two copies of this library would be far, far too tedious. Every time we make a change to the C# version we would have to go make the same change to the Java version.
In a nutshell, the idea is here is to use Mono to execute our C# code and create a bunch of glue code that would make the OpsLib API available to Java. It should be possible for all of the glue code to be automatically generated, although it might take a little time to work out the kinks.
This idea isn't actually all that bad, and we may want to revisit it in the future. But it's not ideal, because it's not "pure Java". Users will need to install the Mono runtime, which is large and must be separately compiled for each operating system. Ideally, we would rather just have a collection of jar files.

So the boundary of the problem looks pretty clear: We want to continue working in C#, but we somehow want that C# code to "Just Work" on a Java VM. We like working with the .NET Framework in Visual Studio, but we want our build system to give us jar files anyway.

How about a translator?

The first thing to observe is that C# and Java are remarkably similar. The syntax isn't all that different, and the runtime libraries have many similarities. Wouldn't it be cool if we had a translator that would take our C# source and generate Java source that "Just Worked"?

I personally find this solution very appealing. It has been a long time, but I still consider myself a compiler junkie. So I decided to explore the idea of writing a translator. How difficult could it be? We don't need a general-purpose translator that can convert any C# program to an equivalent Java program. We simply need one that is just smart enough to slurp OpsLib and output a Java equivalent. Furthermore, we control the input. If we need to make changes to OpsLib to make it friendlier to the translator, we can do so.

(When facing a similar problem, Fog Creek chose exactly the path I am describing. Their bug-tracking system is written in ASP. They wrote a translator that converts from ASP to PHP. Joel's recent article tells the story.)

I started by exploring ANTLR, a very cool parser generator that can output C# code. In the end, I found myself wishing I had a reason to use ANTLR, because I think it's deeply neato. If I were writing a translator from scratch, I would probably start here.

But along the way I realized that mcs (the C# compiler from the Mono project), would make a much better starting point. It already has the parser, symbol table, and type system done. I simply need to make it generate Java source code out the backend instead of IL (the Intermediate Language used by the .NET runtime).

So I started hacking. I spent two days adding a new backend for mcs. I made a remarkable amount of progress, but the experience surfaced a lot of little problems that we would have to solve. For example, Java methods are required to declare any exceptions they throw, but C# doesn't need this.

Eventually we could make this work, but it could take a long time. Furthermore, it turns out that the syntax conversion is the easy part. The class libraries are the much bigger challenge. The Java code converted from C# is still trying to call the .NET Framework, but those libraries don't exist in the JVM.

Enter Mainsoft

In the end, we decided to purchase a solution to this problem from a company called Mainsoft. Their product, Visual Mainwin for J2EE, happens to do exactly what we want. (I have no affiliation with this company other than the fact that SourceGear just became their customer.)

Mainsoft's tool is a Visual Studio add-on which compiles C# to Java byte code instead of to IL. They include a class library that provides support for .NET Framework stuff.

I was ultra-skeptical, but in practice, this tool is working surprisingly well. We had to make very few changes to the OpsLib code, all fairly minor. The resulting Java version of OpsLib passes our suite of regression tests, and that speaks volumes about the quality of work Mainsoft has done. Those tests are truly sadistic.

In the end, we've got a pure Java solution, nothing but a collection of jar files. We can run them on Windows or on Linux.

By purchasing Mainsoft's product, we allow ourselves to keep our primary focus on Vault itself. That's a big win.

The tradeoff is that this product was very expensive. The license agreement contains confidentiality clauses which prohibit me from disclosing the price. Suffice it to say that this product is not cheap.

But the money is now spent, and the decision is behind us. Now I can get back to working on other things, not the least of which is writing this article, which is now several days late.

Okay, I promised I would make a point, and it is high time that I did so, but first I want to indulge in just one more digression. Unless you are the CEO of Mainsoft, feel free to skip the following section.

Some Unsolicited Advice for Mainsoft

Dear Mainsoft,
Your technology is so cool that it seems like magic, but your company has a bug which I think is worth fixing: You are too focused on the Enterprise tier.
I use Microsoft's terminology when I describe the various tiers in the developer market. Your company seems to be completely optimized for the "Enterprise" tier. I understand why, as it is obvious that your products are a good fit there.
The tier just below that is called the "Professional" tier. Your current approach makes it very difficult for you to sell your cool product(s) to people in this tier. Personally, I think it would be worthwhile for you to learn how to relate to Professional tier developers like me.
Don't get me wrong—your service to SourceGear has been quite adequate. Surprisingly, your sales guy was actually not a complete annoyance, and for those of us here in the Professional tier, that's all we really want from a sales guy. I would also like to compliment you on the excellent technical support service we have received. When we found a bug, your team responded quickly and provided us with a fix.
But if you want to reach the Professional developer tier effectively, I think you need some new tricks:
· You need to be more transparent. You are one of the most opaque software companies I have ever seen. A lot of the developers in the Professional tier are active members of a broad community of .NET developers. You'll have to learn how to relate to that community if you want to sell your product to these people.
· You need to develop a "Professional" Edition of your product. Your current version of the product should henceforth be called the "Enterprise Edition". For the "Pro" version, introduce some carefully chosen limitations that would make it unattractive to Enterprise customers. Perhaps you can find a few features to remove that will not render the product too crippled for use by ISVs and other Professional tier developers.
· Finally, the licensing and pricing terms for the Pro version need to be very different from what you are using now.
I encourage you to look closely at these possibilities. There may be enough revenue in the Professional tier to be worth your trouble.
Kinds regards, Eric

"Fine Eric, so what's your point?"

My point is simply this: Virtually all decisions in a small ISV should be made with the involvement of technology person. Most decisions in a small ISV involve issues of both technology and money. These decisions are really hard.

Note that I am not claiming my decision in the story above was absolutely the right one. I've made my share of mistakes in this arena, and I'm sure I will make more. Only time will tell if my decision turns out to be something we will regret.

But here's the thing: I cannot imagine facing a decision like this one without the depth of technology understanding that I have.

I am not comparing my level of 'technical clue' to other geeks. I am merely saying that relative to a non-programmer or a person with a pure business background, I am an absolute wizard on matters of technology:

The decision I made above is a classic example of a "build vs. buy" problem. This kind of decision happens quite frequently in the course of running a software company, but it's still just one example of a decision that involves both technology and money. Such decisions happen all the time at many different levels of management. Getting them right is really, really hard, even for people who can see through all the technology abstractions. When such decisions are made without this expertise, the chances of a good result go way down.

People like to wonder why software companies fail. This is one of the big reasons why.

Most ISVs are founded by a developer. They all begin as developer-centric companies. But sometimes they lose their way as they grow. Somebody convinces them to hire "real management". More and more decisions involve money, and developer involvement in those decisions gradually decreases. Suddenly you find yourself in a big mess.

Company growth necessarily involves growing pains. In a software company, the central challenge of that growth is blending new leadership (people with real management experience) with old leadership (people who understand the technology of the product).

"So you're saying that developers are the only people who are valuable?"

Absolutely not. In fact, my primary worry as I write this three-thousand-word rant is that I will trigger a wave of even higher arrogance among the programmers of the world.

Fellow Geeks, we must strive for excellence not only in our code, but also in our interactions with Those Who Think HTML is a Programming Language. Drawing from a piece of our own wisdom literature, let us not forget the memorable words of Han Solo:

Don't get cocky!

Software developers have a horrible tendency to think they are the most important people in every company. Unfortunately this particular delusion of grandeur has some truth to it, so many of us find it terribly difficult to behave and get along with others.

Nonetheless, my point remains true. The skills of a developer are applicable to many other tasks besides coding:

Companies should not be afraid to let developers get involved in activities other than software construction.

Developers should work very hard to remember that the world does not revolve around them. Without exception, all of the most successful developers I know have a posture of humility.

"But aren't developers missing some skills?"

Absolutely. As developers, we are often just not qualified to participate in things like sales or marketing or strategy. We can be too abrasive to talk with customers. We love certain technologies too much to be objective. We forget that users are very different from us.

Nonetheless, companies must find a way to give our 'technology cluefulness' a voice in the discussion of decisions.

I love reading the various essays written by Paul Graham. Just as a novelist reveals more about his character with each chapter, Paul keeps refining his characterization of the "Great Hacker" with each piece that he writes. After reading his complete works, it is easy to see two things:

In contrast, I just love this little gem that was recently posted on Joel Spolsky's discussion site by somebody who calls himself/herself "comp.lang.c refugee":

Programming languages are chosen mainly for business reasons. I spend most of my time working with languages that I don't really like because the languages that I'd like to work with carry business disadvantages that outweigh their technical merits. That's the nature of the game. I can accept the situation (my choice) or find a new employer. Whining about how I can't use Java or Python or whatever at work just isn't an option.

Fellow developers, if we expect to be heard, we must learn some balance.

"Geeks everywhere? Where does this madness stop?"

It doesn't—it goes all the way to the top.

In a software company, there are very few positions where 'technical clue' is not an asset. From the lowly summer intern all the way up to the CEO, a person with deep technical understanding can add more value than the same person without. Joel Spolsky said it this way:

If you ask me, and I'm biased, no software company can succeed unless there is a programmer at the helm.

I am inclined to agree.

"But... but... what about Steve Ballmer?"

Is Microsoft an exception to my rule? I can't say. Some Microsofties say that Bill Gates occasionally walks into the office of a random developer and instantly understands the code at a deep level. Others claim that Bill is 7 feet tall and can shoot lightening from his fingertips. I've never worked there, so I don't really know if all the legends are true.

But I have long believed that Bill's deep technology expertise has been a critical factor in the success of Microsoft. Bill presided over the ascent of Microsoft to its incredible levels of success. I cite Microsoft as an example of my claims, not as a counterexample.

But I still think it is fair game to ask if Microsoft is losing some of its developer-centric foundations now that Steve is the CEO, as long as we remember two things:

First, Bill is still very, very involved.

Second, Steve may not be a programmer, but there's a geek inside him that wants to come out. I checked Steve's background and discovered he has a Harvard math degree. More importantly, a little Web searching easily reveals the hilarious video of him dancing around the stage chanting, "Developers! Developers! Developers!" This guy is no pretty boy CEO (examples of which my editor would immediately delete, so I won't even try). Strictly speaking, this guy may not be one of us, but I'm inclined to trust him.

That said, I still can't resist offering:

Some Unsolicited Advice for Steve Ballmer

Dear Steve,
I just bet that you periodically ask yourself the following two questions:
· Has Microsoft become less developer-centric since I took over as CEO?
· Should it?
I honestly don't know the answer to either of these questions. Like any great company, Microsoft is constantly changing, evolving, and maturing in an industry that moves very quickly.
But if you ever get the impression that the hardcore developers need more voice in the company, I have a suggestion for you: Get Microsoft to formalize a well understood career path for developers to move into marketing.
In my opinion, Microsoft is already the industry leader in helping developers apply their skills in other areas. You guys created the idea of a "Program Manager," a developer who writes specs instead of code. As another example, I think of the SDET (Software Development Engineer in Test), a developer who writes testing code instead of product code.
I am simply suggesting that you develop a similarly well-understood way for developers to apply their understanding of software architecture and construction to the challenges of product strategy. Microsoft would benefit, and many other companies would benefit. The rest of the industry tends to follow your lead on things like this.
Have a nice day, Eric

Back to the Matter at Hand

OK, let's take a step back and review. I just gave unsolicited and probably clueless advice to the 24th richest man in the world. I can't shake the feeling that this article took a wrong turn somewhere. I'll try to get back on track here just before I wrap things up.

Perhaps the best way to end this article is with a few remarks about what this all means for the micro-ISV. The following is an example of one of the most common questions I get from developers who are creating a brand new software company:

Where can I find a partner to be a co-founder and handle the business side of things?

My answer: Don't.

It is common to see software companies starting out with two founders, a geek and an MBA. Do you really need the MBA?

If I were to oversimplify the message of this article, I would make two statements:

  1. Developers add more value to a software company than anybody else.
  2. The truth of statement 1 is inversely correlated with the size of the company.

When a company is very small or just getting started, nobody can add value as well as a developer because there isn't really much other stuff that needs to be done. You don't have customers yet.

Yes, there are obviously a number of non-coding things that have to be done, but those things are a part-time job. You don't need a full timer, and certainly not a co-founder, and most certainly not one with an MBA.

Do all that stuff yourself. You need the experience anyway. If you really want a partner, don't find an MBA, find another geek like yourself. Don't be afraid to allow your company to be very developer-centric for a very long time. By doing it this way, you'll avoid a lot of problems and you'll learn a lot.

 

Eric Sink is the non-legendary founder of SourceGear, a developer tools ISV located in Illinois. More of Eric's writings and rants can be found on his weblog 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.