From Yakov Fain's blog

Vacations are meant for reading. This time I’ve picked a book “Eric Sink on the Business of Software”. This blog is not a review of this good book, but rather my own thoughts and comments inspired by reading about running a small company that develops software.
These comments are based on my own experience in this field.

I like these quotes from Eric’s book:

• “I like the smell of a freshly killed bug.”  Very well said. I’d take it one step further and submitted to Wikipedia the following  definition of a geek: “Software geeks are people with a smell disorder. Most of all they love the smell of a freshly killed bug”.

• “Good communication is not 50% listening and 50% talking, It’s more like 80% listening and 20% talking”. Very true. Can you listen to someone other than your boss or wife without interrupting for more then 3minutes? If yes, you have no problems with communication skills.

• “Your ideas are worthless”. Exactly! There is long and winding road between your great idea and a PRODUCTION QUALITY software product.
• “The purpose of 1.0 is to help pay for the development of 2.0”. This means don’t try to put too many features into the first release of your product – get it out the door and start making some money.

Eric’s message about not using your house as collateral for your business is not strong enough. My message is this: “Do not even think about it!”

One day you came home telling your wife, husband, or a domestic partner that you’ve got an idea about developing a software product that will change your life and make you rich.  But to implement this idea, you need some cash – let’s take a second mortgage to get this cash from your house. The only proper reaction of your wife, husband or a domestic partner is showing you a middle finger.  No, there can’t be any special circumstances that would justify a chance to lose your house if you made a mistake.  If this idea is that great,  why won’t you try to convince anyone other than wife, husband or a domestic partner to shell out some cash for implementing it? It’s not easy?  I know. But maybe this means that your idea is not that great? Fine, if you still believe that this software product is your future, go ahead – start spending extra 5-6 hours daily (after your paying job) developing your product, or get a second job if you need to hire a software developer.

I had and still have lots of ideas, but over the years I came up with the following cold-shower technique. Let’s say, you have an idea of THE software product. Assume that you’ve already created it. Turn on the time machine and visualize the day when you’ve completed development of your one-of-a-kind-state-of-the-art software program. Congratulations, but what’s next? What are you going to do with it? Can you sell it to at least one person? Price does not matter. Can you make anyone pay even $10 for your creation?  How are you planning to advertise it? Do you have even a slightest idea about marketing? Do you have the budget for marketing? Your Web page explaining the revolutionary effect of using your newborn baby will go unnoticed unless you will be constantly promoting it.
 
Eric’s book is about creating a small Independent Software Vendor  (ISV) company that creates profitable software. He mentions that there are companies that do both – develop software and offer consulting services, and this is how his company has started.

I’m also partner in a company that does exactly this – we develop software components and plugins and offer consulting services as well. This business model allows us not to carry all eggs in the same basket. It has the following advantages over a product-only ISV:

1. Having two sources of income (consulting and product sales) is better than one. This is a no-brainer.

2. Both of these business activities complement each other dearly:
    a) the money earned by consulting gigs can be used for the software product(s) development. Such internal investment is a lot more attractive than asking for venture capital (VC) elsewhere.

   b)  it’s a lot easier to get consulting gigs if you are also an ISV.  The fact that you can develop some advanced software adds a lot of credibility to your consulting services. This really helps us to stand out from consulting body shops that try to bid on the same projects.  Our negotiations of new consulting gigs are not marketing shpiels played by the sell reps in expensive blue suits, but rather highly technical conversations with perspective client’s geeks and CTO’s.

3. If our software product sales won’t be as good as predicted, we won’t need to turn off the light in our business.  Armed with the knowledge gained during product development, our technical skills (so needed in the consulting business) are always up to date, which is pretty easy to show.

Venture Capital

To use or not to use VC is not an easy question. VC does not come for free – investors want a piece of the pie and bring stress and pressure to the life of your small company. If you are using internal funding, having a month without revenues is no big deal. But with external funding it may be a problem. Eric writes, ”For a company that was built with somebody else’s money,  operating at a breakeven is a failure”.

It’s not easy to get VC funding even if you want to go this route – most of the VC won’t even consider investing into a small ISV unless it can show some serious annual revenue ($1M may not be enough).

I am on page 65 now, and so far I disagree with only one Eric’s statement: ”I obviously need their [customers] credit card information, but I discard it immediately after the sale is complete.” I do not think that a small ISV should even bother writing a module that charges customers credit cards. This has to be done by professionals that are specializing in this business. We use PayPal for dealing with payments, which means that do not even know our customers’ credit card info. Our logic is simple – we do not want to deal with even a single payment related issue. This is not our cup of tea, and let professionals handle it. We pay 2.5% percent or so from each transaction to PayPal, but we sleep well at night knowing that this area is taken care of.

People

A small ISV just can not afford hiring the wrong people (both employees and contractors). Wrong people are the ones that are either not technical enough or do not have proper communication skills. For example, we’ve had a technically sound worker who did not like answering emails. After our three failed attempts to get the status of his assignment, we had to fire the guy. Larger firm would never do something like this, but a small ISV just can not afford to have such a peron. Yes, it’s a pity that we’ve invested some time into this worker, but we can’t make success of our company dependent on the mood of one programmer (even if he’s has good technical skills). 

We had to let go another person after about two month of employment – he was not good enough technically.  Hiring this guy was a mistake in the first place, we’ve lost several thousands of dollars on him, but we must cut the losses quickly, learn from our mistakes and move on. Large corporations have lots of dead wood, which burns large chunks of their profits. Small ISVs should not tolerate this.

Eric does a good job explaining the difference between programmers and software developers, and he makes a very important statement, “a small ISV should not have any programmers”. This statement might sound strange, but it’s not if you realize that  programmers are the people who just write code and do nothing else. Not to be confused with people called software developers, which do many other things like talking to users, making decision, perform testing and ARE CREATIVE.

Our small ISV company has people working in different countries, which makes having programmers (not developers) even a bigger no-no. Unless you can afford writing crystal clear specs for programmers, which small ISV can’t, having programmers is expensive even if you pay them relatively modest salaries. They may not understand (and care) why they were asked to write this piece of code. The worst scenario takes place because of the time difference: you give them an assignment TODAY, and TOMORROW they respond that they did not understand it. It’s a bummer. You’ve lost a day, which may affect your deadlines, and the salary paid to this person for yesterday’s work was paid for nothing.

My short vacation is coming to an end, and I’ve completed a half of Eric’s book. I like the book, and will finish it one day. But I will follow his own advice – do not read one book on business of software – read ten.