The Business of Software

Are you an entrepreneur? Tired of your job? Are you a developer thinking of starting your new software company?
If so, you must read Eric Sink's book: The Business of Software.

I've just finished reading this VERY interesting book oriented to those entrepreneurs like me, that are willing to start a software company. I founded my own company three years ago, but the company wasn't mine altogether, I owned just 25% as we were four partners. So in the first two chapters of the book I've seen myself in some respects during my time at that company. I totally agree with Eric in many things.
The book is focused on Independent Software Vendors (ISV) which means that you have to have a product. I'd say it is actually focused in micro-ISV which means that the company starts with a single person. For those reasons, my ex-company does not match the topic exactly, as we started four and without any particular software product.
Here you go a few points that I learned with my company and you won't read in Eric's book (They are just an excerpt as I'd need a whole chapter to write about the whole experience):

  1. You have two choices when starting a software company:
    a - Develop software products and try to sell them as Eric says
    b - Base your business on services: Support for open source software, custom made software, servers, networking, hardware, etc, etc, etc.

    What I think:Never choose option "b" if there is no market in your place. Your prospective customers will be mainly in the area you work and you won't success if they are not willing to pay for technology/software. Custom made software is more expensive than you might think and it will be really hard (to not say impossible) to get your customers pay off its actual value. At least in small cities in Spain, option "b" is a suicide.
  2. Dont's start with any partner, no matter how good friends you are and of course, never ever work with your wife:
    The reason to have a partner has to be the same than the one to hire somebody. Read the section about "Hiring" in the book. Your need for a partnership has to be even stronger.
    In case you are several partners, make sure everyone has his/her role, and the roles are different. Anarchy does not work on companies. Take a path and follow it till the end, focusing as much as you can. Don't take several paths at the same time. Have every partner absolutely responsible of her liabilities and trust her.
  3. If you work on services, don't spend money in Trade Shows. You have to be there because you have to, (so yes, better you go) but don't spend any money in gifts for people or in a super appealling booth. Invest your money advertising in the Golden Pages and other local publications where people look for service providers.
  4. Even if you use test driven development or any other methodology where you test the software, have a bunch of people in the QA team before releasing any product to the end customer. This might sound obvious but I know many companies that don't have any QA team.

I won't tell you which of these decisions we made at that company, these are just my thoughts, regardless of what we did or we didn't. Maybe in twenty years I'll write a book on all my experiences and experiments and tell the whole storie of my business aventures.

Now, more things about the book. I knew about Eric two years ago when I found his excellent article "Developers Not Programmers". Before moving to Ireland, I sent him an email asking for job and he sent me a friendly answer saying he didn't need developer at the moment. Since that, I've followed his blog at and I highly recommend his book.
I've learned funny things (sometimes crazy) about the American culture. I appreciate the most, the chapters on marketing and sales. Did you know that Eric worked on Abiword and Internet Explorer from their beginning?
I found very interesting the sections talking about .Net and platforms.
Look at this algorithm at page 137:

Idea FindGoodProductIdea()
ArrayList candidateList = BrainstormLotsOfIdeas();
return ChooseTheBestIdea(candidateList);

Brillian, isn´t it?

I am going to start my own company again, but this time things are going to be much more different. I'll be a micro-ISV and will leverage many ideas from the experience of Eric. Thanks Eric!

What I think about WPF after all

I'll try to not bitch anymore about technologies as any of them have good things and bad things after all. I complained a lot about WPF (Windows Presentation Foundation) time ago as I was using it for an application that should have been done using Windows Forms and I think that is not fair. After that I tryed some animation stuff and I found out the actual asset of this technology.
With XAML you can write impressive 3D animations among other cool effects to make your GUI more attractive in some cases. Have a look at this article written by Charles Petzold... very nice, isn't it?
The animation engine is also very powerful and confortable programmatically... say for instance that you want your forms appear fading in, from 100% transparent to 0%. You only need 1 line of code:

What I think now is that WPF is not ready for business applications where Windows Forms fits really well and has far more maturity and features. I think it has not been designed for that as a priority. WPF is suitable for special GUI applications that require nice effects and maybe in the future it will be ready for any kind of application. As many people say, I see programmers adding weird animations on screens or controls that don't need such a bad user experience, just because it looks cool to them. But that is not a technology problem.
Nobody teaches developers how to desing GUIs and this is REALLY important if you consider the user the most valuable part of the game, as I do. I'll post about that in the future.

Refactoring:Improving the Design of Existing Code

Last book I've finished reading is probably the first one I should have read since I started my software development career: Refactoring is a masterpiece of Martin Fowler with important contributions of Kent Beck and other brilliant architects. In every chapter I asked myself why didn't we study this book in colleague. The book was edited in 2000 but refactoring is not new. I remember arguing with my programming teachers things like, why a method had to have a single end point, things they taught us wrong. As we all know, university is far behind reality and it takes a long time for them to teach new trends so maybe within a decade people will teach refactoring and test driven development in colleague. By the way, here you go a nice article of Joel Spolsky on the Computer Science degree.
Martin Fowler is so far the best writer I've ever read in english. I've learn a lot of english reading his book, it is very expressive and has a nice literary style.
The firsts chapters talk about refactorings that are defined in detail later on so I'd recomend reading the book twice.
Although the book uses Java code, it is perfectly applicable to .Net, and some refactorings let you see some advantages that .Net has over Java, as having object references rather than objects by value.
Some nice sites on refactoring are:

Eladio, I hope you enjoy this book 🙂