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.

The IP Goose

One of the problems with being a software developer these days is company Intellectual Property agreements. I understand that companies want to protect the time, money, and expertise that they have invested. But some of the agreements I have seen go way past reasonable concern. Some IP agreements take the position that any programming a developer does should belong to the company. This includes software that was developed off company premises, without company resources, and in fields that have nothing to do with the company's business. On the face of it, this seems a bit overboard.

Just to be clear, I do not suggest that companies give up all IP agreements. A company needs to be able to protect the work that they have commissioned. They also need some form of protection against an unscrupulous individual taking their proprietary knowledge and going out to compete with them. On the other hand, taking too hard-line a stance can have consequences. I'd just like to suggest that companies consider the tradeoffs involved.

Consequences

So what are some of the consequences of a too-strict IP policy? The simple answer is that these agreements discourage programmers from programming in their free time. These kinds of agreements also make it impossible for a programmer to work on any open source projects. These projects normally require that any code a programmer submits to the project be unencumbered by any IP agreement. If everything a programmer touches belongs to the company, the programmer cannot work on open source projects.

Many management or legal types might take the position that protecting company assets is more important than a programmer's ability to program in his or her free time. Unfortunately, this is a very short-sighted view. This viewpoint ignores some important facts.

• Programmers improve through practice.
• Open source projects are a great way to improve skills.
• Many programmers have (programming) interests outside of work.

Practice

Although many non-programmers don't realize this, a programmer requires specialized knowledge and skills to program well. These skills can only be improved through practice. Some people are born with more inherent programming aptitude than others, but all programmers need practice to enhance and maintain their skills. Really good programmers often find themselves writing code even when they don't have to. Interestingly, it seems to be less important what you are working on, than that you are continuing to use those skills.

Programming on different projects, with different groups of people is a great way to extend the programmer's skills and knowledge. Different experiences tend to make the programmer more flexible in his approaches and more aware of best practices. Open source projects are a great way to see how other people develop software and to be exposed to other methodologies and approaches. The more experience a programmer develops, the better his or her skill set.

Projects

One thing that would probably amaze the legal and management types that craft those IP agreements is that many of their programmers will tend to work on completely different kinds of programming outside of work. This makes it less likely that the software the programmer develops will have any relation to the company's business. There are some exceptions to this, but many of us program differently for fun than we do for work.

Although some programmers will work on work-related code in their free time, the work generated could be protected by much more restricted agreements than many companies generally use. Moreover, in many cases the programmer in question intends to provide the completed product to his employer anyway, but needs to work on it outside work hours for political, personal, or (in rare cases) technical reasons.

Word of Mouth

One important point that many companies forget is that programmers do discuss work environments with each other. Any company that employs tactics that make our work less fun or interesting will find that the word will get out, making it more difficult to find and hire the best. Conversely, a company that recognizes the tradeoffs involved in the IP agreement may find word of mouth makes it easier for them to hire better programmers.

The Goose

I remember a fairy tale from when I was young about a goose that laid golden eggs. It sometimes seems that many people have never heard this story. One version of the story can be found here. The important part of the story is that the farmer lost the steady flow of gold eggs by trying to get everything at once. In a way, this is similar to the strict IP policy. By trying to capture all of the output of each programmer, the policies may prevent a steady stream of innovations that come from better skills and wider knowledge.

Some very big companies have begun to realize the benefit of this approach. In recent years, IBM has been providing support, cash, and personnel to open source projects. This has allowed them to reinvent the company and has helped to make IBM a place where good programmers would want to work. I don't know what their IP agreement looks like, but I would guess that they have put more thought into it than many companies.