Programmer Musings

Review of Micro-ISV: From Vision to Reality

Micro-ISV: From Vision to Reality
Bob Walsh
Apress, 2006.

This is not the sort of book I would normally read. I'm usually more interested in the technical side of software than the business side. I found this book to be particularly difficult going partly for that reason. But, before I get into what I didn't like about the book, let's look at the positives.

Walsh manages to give the most complete overview that I've ever seen on what you will need to start a small software business. I'm an unabashed techie. One reason I've never attempted to start a business is that I know that I have big gaping holes in my skill set where business skills are concerned. Walsh's approach is the only one I've ever seen that gave me some reason to believe that I might actually be capable of starting a business. It also gave me a good idea why I probably never will.

Instead of pithy phrases and advice, Walsh focuses on explaining what sorts of information a technical type will need to learn to start down this path. He also gives plenty of information on where and how to track down the information you need. Instead of attempting to spoon-feed us the business information we need, he shows how to learn business skills just like any other skills we have learned throughout our careers. In other words, this book does appear to be focused on helping technical people (who basically learn for a living) to see what they will need to learn to start a business. This seems to be a much more reasonable approach than others I've seen.

Despite the intelligent approach, I found the book to be an incredibly hard read. It was not the writing, which was quite clear and readable. It was the subject. I found it very hard to focus on the material. If I were more interested in starting a business, that might not have been an issue. I also had some difficulty with Walsh's reliance on interviews for many of his points. In a smaller quantity, I think it would have been helpful. But, at some points, it felt more like the testimonials you see in informercials. I am just not normally convinced by that approach. I would have been more comfortable with a few more numbers and a few less stories of people who are succeeding in this field.

The second to last chapter was really difficult because of the sheer number of interviews focusing on Microsoft business support services. It's nice to know that those services are available, but there were enough of those interviews that it began to feel more like a commercial for Microsoft than I would have preferred. Fortunately, that was mostly concentrated in part of one chapter. Most of the interviews seemed more informational than that set.

The final interview of the book was also a little overdone in my opinion. Walsh interviewed Joel Spolsky for an amazing 10 pages of text. In addition, Joel did the foreword for the book. Now, I find Joel's insights to be interesting and he's a good writer. But this was a significantly bigger chunk of text than any of the other interviews. Frankly, if I wanted Joel's opinions, I can get them in many other places. It did not seem necessary to devote quite so much time to them here.

Despite my criticisms, I think this is probably a really good resource for any technical person who is thinking about starting a software business. This will either give you a leg up on the information you will need to know, or convince you that you are not cut out for this kind of life. Either way, the information may be exactly what you need.

Domain Specific Languages, a Renewed Interest

I've seen quite a bit of interest in Domain Specific Languages (DSLs) on the Internet lately. Some good examples include Martin Fowler's exploration of the subject:

* MF Bliki: DomainSpecificLanguage
* Language Workbenches: The Killer-App for Domain Specific Languages?

He does point out that this is not a new idea. He uses Unix as an example of a system that uses a large number of DSLs. The subject has gotten enough interest to reach the point where people are discussing when it is a good approach to apply (Artima Developer Spotlight Forum - How and When to Develop Domain-Specific Languages?). Others are beginning to apply the term DSL to extend their area of interest (Agile Development with Domain Specific Languages).

So, from this we can guess that interest in DSLs is on the rise. As Fowler pointed out, Unix has been a nexus for the creation of DSLs, including:

* make
* regular expressions
* awk
* sed
* yacc
* lex
* dot

and many more.

Recently, I have seen the suggestion that extending or modifying a general purpose language is a powerful way to build a useful DSL. To some extent, this is also well-trodden ground. The classic example of this approach was implemented using preprocessors to provide facilities not present in the original language, both Ratfor (for structured programming in FORTRAN) and cfront (for object oriented programming in C) used this approach.

A recent article, Creating DSLs with Ruby, discusses how the features of the Ruby language make it well suited to building DSLs without a separate preprocessing step. The Ruby language apparently supports features that supports creating simple DSL syntax that is still legal Ruby code.

This is a very powerful technique that is not very easy to do with most languages. Amusingly enough, this technique is also not very new. In fact, there was a general purpose programming language that was designed around the concept of writing a domain language: Forth. If I remember correctly, Charles Moore once described programming in Forth as writing a vocabulary for the problem domain, defining all of the words necessary to describe the answer, and then writing down the answer.

The Forth language is different than most programming languages you might have encountered because it has almost no syntax. What looks like syntax is actually a powerful technique for simple parsing, combined with the ability to execute code at compile time. This allows for extending the capabilities of the language in a very powerful way. One interesting effect of this feature is that many good Forth programmers naturally gravitate toward the DSL approach when solving problems above a certain level of complexity. We firmly believe that some problems are best served by a language, not an arcane set of configuration options.

Forth does give us an important insight into the problems with DSLs, as well. There is is a well-known joke among Forth programmers:

If you've seen one Forth...you've seen one Forth.

Unlike more traditional programming, Forth programs are built by extending the language. A new programmer trying to learn a Forth system needs to learn the new dialect including the extensions used in this environment. This is not technically much different than learning all of the libraries and utility classes used in a more traditional system, but there is a conceptual difference. In Forth (or a DSL-based system), there is no syntactic difference between the extensions and the base language. The language itself can be extended without an obvious cue in the code to say when you have changed languages. This means that a new programmer may not recognize a new piece to learn as readily as when seeing an obvious library call.

This becomes a very important tradeoff: Which is more important, ease of learning for new programmers or power for advanced users? A well-designed DSL gives the advanced user a succinct notation to use to express hie or her requirements concisely and precisely. This is the appeal of the DSL. The downside is that this represents a new set of knowledge for each programmer relating to troubleshooting and debugging. It also requires more care in the design to develop a consistent and usable notation.

As usual, the tradeoff is the key. We need to be able to decide if the benefits outweigh the disadvantages and build the system accordingly. I wish there was a magic formula that could be applied to tell how or when a DSL would improve a system. Unfortunately, I have not seen a sign of such a formula yet.

Programming and Writing

Over the years, I have come to the amusing realization that many people feel like they could program if they just tried. You know the type. He (or she) has used computers for a while. He picked up Computer Programming for Total Morons or Object Oriented Programming in C++ and Java in an Hour and a Half and now expects to be able to write code like a pro. Those of us who have been programming for a while, brace ourselves for the inevitable opinions and declarations about building large systems based on experience with single-page programs.

I have also realized that there is another field that is very familiar with this problem, writing. Similar to the way that many people seem to think that they can program just because they can enter code in an editor, many people also seem to think they can write just because they can put words on a page. Ask anyone who really writes for a living and they can tell you how little the ability to write words on a page has to do with actually writing. Despite this disparity, anecdotal evidence suggests that many people still expect to write a great novel someday. (Although, I suspect that percentage is smaller than it was a few decades ago.)

A couple of years ago, I compared writing and programming in The Recurring Myth of Programmer-less Programming. I made a very superficial connection between these two disciplines in order to make a very different point. Since then, this connection has been simmering in the back of my head and I have come to realize that they have more in common than I originally thought.

One thing these two disciplines have in common is communication. Now, I realize this is not a particularly earth-shattering revelation, but bear with me a bit. It often comes as a surprise to most people that communication is hard. If you are just talking with your friends, family, and co-workers, you probably manage to be understood most of the time. When misunderstandings do arise, most people seem to assume that someone wasn't paying attention or something.

The first time you try to communicate with someone from a different culture, you begin to see how hard communication can be. Even if you can speak a common language, misunderstandings abound. If you are communicating through a low-bandwidth channel like email, communication becomes even harder. Most people seem to assume that these kinds of communication problems are the other guy's fault. Really communicating doesn't allow for that particular cop-out. Cicero is supposed to have said

The aim of writing is not simply to be understood, but to make it impossible to be misunderstood.

This is much harder than most people realize. When you are speaking, you can watch your audience and clear up misunderstandings as they arise (at least in theory). When you are writing, you don't really know who your audience is. There is no feedback, so misunderstandings linger.

In programming, this is equally hard because your writing has two very different audiences: the computer and other programmers. The difficulty comes from the fact that the computer needs everything described in mind-numbing detail. It cannot make the leap from one concept to another. On the other hand, people (even programmers) are not very good at reading information at that level of detail. This difficulty of working at two very different levels at once is one of the things that separates an actual programmer from a coder who dumps code into an IDE or editor.

Thinking and communicating at these two very different levels is extremely difficult. Over the years, we have developed better programming languages to reduce the amount of detail we need to explicitly write for the computer. Unfortunately, this has not made the complexity go away. Instead, the programmer has to be aware of the details of each statement and the context in which it is made. While this is somewhat easier for humans than the alternative, it does not mean that the details have gone away. It just means that you don't have to think about all of them constantly.

A good programmer has to be able to think at multiple levels of detail at the same time. These levels include:

• user-level details of the solution, such as the desire to select items by name
• high-level details of the program, such as the need to find items quickly by name
• medium-level details that the program needs, such as data structures and algorithms appropriate to the job at hand
• low-level details that the machine requires, such as limits on data types, memory, and speed of the processor.

Not all of these details matter all of the time. But a good programmer has to be aware of them and know when particular details can be ignored. The programmer also has to be aware of the constraints and requirements of the problem he (or she) is trying to solve.

A good programmer is aware of multiple solutions to many different problems and is capable of making various trade-offs in choosing between them. Whereas a coder has probably found a solution that has worked in the past and tries to apply it to every problem.

Fortunately, some coders eventually gain enough experience to become actual programmers. Unfortunately, the percentage of coders that become programmers is probably close to the percentage of people that actually do write their great novel. Unfortunately, unlike potential writers, these coders are actually producing code that someone will need to maintain and repair.

Now, sooner or later someone is going to point out that here I am writing, when I have no business claiming to be a writer. Actually, I don't claim to be a writer. I think my best credentials for writing are that I know I'm pretty bad at it. For that reason, I work pretty hard at each article I write, trying very hard to get my point across without leaving too much probability of being misunderstood. As such, this article has been one of the hardest for me to write.