Ahh, the in-room coffee pot. Yes I’m going downstairs soon to toast an English muffin, but first coffee…
You know the one about why man-hole covers are round? The makers of this coffee pot didn’t get the memo.
Water temperature in the shower ranges from arctic to frigid. Where’s that coffee?
The second (potential) customer we’re visiting today is having an in-house mutiny. Some want to use our software to do their code reviews, others want to write their own.
There are, of course, reasons to build versus buy, but typically in our space the “build” argument is pretty thin. Any time you have integration (code review system with version control, code review system with issue tracking, code review system with diff tool) you have a never-ending string of little problems.
Take integration with Perforce. When Perforce is about to come out with a new release of their software they send it over to us with a version history so we can check it out. We’re able to run our complete unit-test and integration suite on multiple platforms for both client and server, including combinations of earlier versions of both our software and Perforce’s.
So by the time the customer installs the new version of Perforce (and possibly the new version of Code Collaborator, in case some changes were necessary), everything works.
If you build it yourself, who is going to baby-sit this and the litany of feature requests? Who’s going to field tech support for Safari? Typically one or two people get this role. Call it 1.5 annual developer salaries. Out here (Milpitas), ballpark estimate for this is $250k per year once you include all expenses.
That’s $250k per year. Instead of 1/10th that if purchased from us. And the in-house tool will never have as many features (even creature-features, not just “stuff we don’t need anyway”) as we will with our small but determined army of top-notch developers.
The usual counter-argument is “We’ll get exactly what we want.” More accurately, you get exactly what you build. You know that what users want and what features are required to let them work effectively are two different things. You know that it takes time and iteration to get there. This will be a full-time software project like anything else, otherwise it’s not going to be good.
So we’ll see how this demo goes. It’s always interesting to hear exactly what someone wants. Often it shows the way to great new features. Then everyone’s happy.
Out of coffee…