* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Build vs Buy

I think the problem in selling to the developer market (and to software companies in general), is they don't understand the economics of build vs. buy.

For example, in the JOS forum, a poster said that his firm was going to write their own bug tracker.

Unless the available tools on the market (both free as in Bugzilla, and commercial like our host's FogBugz) don't meet your critical needs, why would you spend more time/money writing your own bug tracking code?

Could it be the "good vs great" problem, where manager-types aren't happy until the program does *precisely* what they want, as opposed to a program which does 80-90% of what they want and need?

Everyone thinks they can write something "in only a few days", when in reality it's always more costly and difficult than they expect.

How do you get past that attitude when trying to make sales?
example Send private email
Saturday, March 26, 2005
 
 
Tell them that "Most companies on average spend X dollars per hour of employee time spent on internal projects that could be better spent generating revenue.  (Don't ask them how much they actually spend.)  Our product costs you Y dollars, so if your people can implement a similarly polished product in X/Y hours, then by all means, it's worth your time."

If they spend $100/hr and your product costs $800, you are pointing out that they'd have to write your product *in a day* for it to make sense.  Using only one employee.
Aaron F Stanton Send private email
Saturday, March 26, 2005
 
 
"why would you spend more time/money writing your own bug tracking code?"

This is simply another sad example case of NIHS...Not Invented Here Syndrome. This terrible disease disrupts the electro-chemical process required for rational thought, causing a dramatic increase in hubris followed by delusions that he or she can "do more in a weekend than *that* lame-o company could do in a whole year, god damnit!".

Myself being a long time sufferer, I am resigned to the fact that I will continually be writing my own XML parsers, relational databases, UI toolkits and...uh...bug tracking software.
NIHS Sufferererer
Saturday, March 26, 2005
 
 
A lot of companies will respond that they're paying the employee anyway, so he may as well work on an in-house bug tracker instead of something else. The argument that it's cheaper to buy than to build is lost on them because they can only think about the check that they'll have to write.

I had a job where I had better electronic test equipment at home than at work. In all the years I was there, the owners couldn't be convinced that investing $1,200 in a single piece of equipment to replace the 20+ year old one would pay for itself times over quite rapidly in the amount of development time it would save.

But sometimes they're right. If that $800 is $800 per seat and they have 7 developers,  3 testers, 1 test lead, 1 project manager and 1 technical writer all of whom need access to the buglist, then that's a $10,400 check. Suddenly, having a simple tool written inhouse looks like it might be worthwhile.
lw Send private email
Saturday, March 26, 2005
 
 
Product X Version 1.0 Cost Calculation

Product X cost    = $100
# of Developers    = 10
Cost of Buying    = $1,000

Hourly Developer Cost  = $100
# of hours to build    = 200  (~one month)
Cost of Building        = $20,000

Total Cost Difference Ratio = 1:20 ($1,000 vs. $20,000)

Version 2.0
Upgrade cost      = $50
# of Developers    = 10
Cost of Buying    = $500

Hourly Developer Cost      = $100
# of hours to fix bugs      = 10
Cost of Building            = $1,000

Total Cost Difference Ratio = 1:14 ($1500 vs. $21,000)

As you can see, the gap is closing fast, if the company is just looking for the bug fixes but not new (useless) features.  With the Buy camp, you have no choice but continue paying for the new features.  Over time, it is no doubt the gap will eventually disappear.

Bonus Benefit of the Build camp.
-    Add New Features that isn’t offered by the new release
-    Timely Bug Fixes.
-    Unlimited Licenses.
-    No unwanted new feature tax

Of course, there are other factors to consider such as:
1.    # of Developers
2.    # of Hours to Build
3.    Initial Product Cost
4.    Upgrade Cost
5.    Developer Competence
6.    etc.

A sad fact is the Buy camp usually assumes there is exactly ONE developer, therefore the cost difference appears LARGER than it actually is.  It is no doubt that it is almost always a good idea to “Buy” if you are in the one-man army.  But the build becomes a viable alternative as the number of developer increases.
RM Send private email
Saturday, March 26, 2005
 
 
If a software package costs $800 it has at least a few hundred hours of development work put into it.

Even 10.000 is not a large amount anymore when you take that into account. You're basically making software for only one customer (yourself). That's very inefficient.
Zorg
Saturday, March 26, 2005
 
 
Most managers don't understand "build vs buy." It isn't limited to software development.
Peter
Saturday, March 26, 2005
 
 
The other reason I see for developing in-house is capital costs. Most companies capitalize any purchase above some threshold (say $2-5 K).

Usually a department will budget a certain amount per year for capital expenditures. If they decide to purchase something that wasn't on their planned purchases list, they face a lot of internal politics and budget change approval processes, etc. Basically, it's a black eye for the department manager and often it will be greeted with a NO from the C-levels anyway.

So, the departmental manager realizes that the development of in-house tools will fit within their discretionary (non-capital) budget and away they go.

Maybe it's not the best way to manage an accounting system, but I've seen this sceanrio play itself out at several organizations I've been with.
Cowboy coder
Saturday, March 26, 2005
 
 
We see this all the time as well and it's not worth arguing with someone who thinks it's smarter to build vs buy.  When you provide the arugment: "your true cost of build is $X per hour x Y hours for development", they come back with stupid arguments like "yeh, but we have people who are currently not doing anything anyway and they're already on payroll".

In these cases we just let them do their "build" and as they run into problems and need more functionality, we get them later.
Hamid Shojaee Send private email
Saturday, March 26, 2005
 
 
Sometimes it is much simplier. Department within organization has funding to keep developers busy with any internal project, but does not have extra $$ to buy better tools or 3rd parties products.
Eugene Send private email
Saturday, March 26, 2005
 
 
Unfortuneately, the Not Invented Here syndrome is constantly reinforced by the multitude of crappy commercial products and open source available. How many times have you donwloaded some sample code or bought a control only to find out that the time you spend fixing it or working around its problems greatly exceeds what you would have spent just writing it from scratch?

The other problem is that people do not look at each situation independantly. They assume that since they got burnt once on some crappy open source control that they must all be that way. Additionally, they perform apples to oranges comparisons by not including the scale of the project into the decision to build vs. buy. Building your own edit mask control vs. buying uses completely different criteria from a decision to build vs. buy your own database replication system.
matt
Saturday, March 26, 2005
 
 
Our company ideally targets developers (an autoupdate program), so I know exactly the type of problem described here. We do occassionaly get customers who freely evaluate our software, ask us plenty of questions, and then finish off deciding that they prefer to write their own. This is fully understandable as many developers do not feel comfortable using other people's code. Big companies in particular would rather spend $10,000s developing exactly the same product that we sell for approx $100 because they end up having full ownership of the source code. I would say that the issue is less the cost trade-offs and much more the fact the without source code ownership many developers feel a loss of control and dislike the inability to fix problems or extend the applications usage.
Simon@AutoUpdate+ Send private email
Sunday, March 27, 2005
 
 
Software providers are often set up to be faceless. When I want something, I want to know who I'll be involved with. At the computer shop, is there a good guy/gal who knows where to order things which aren't easy to find? Will a support person at a software company give a damn about my problem?

And how safe is their employment? Will they be fired just because they committed a silly indiscretion with the secretary and a stuffed penguin doll? Then thanks but no thanks.

Frequently, I don't think a product is talking to me, but rather to a market. "We want you to know that maintaining the relevantness of your business investment with industry-quality design patterns is job 1.0! Look at these icons signifying parts of your workflow!"
http://www.borland.com/together/

And software like FogBugz seems political to me. I once hired a close friend for mainly political reasons (but he was very good, solving a couple problems straight away), and I think in an unfortunate environment, I'd pick enlightened software to gang up on crappy software. Set a good example maybe, particularly since non-programmers touch Fogbugz.
Tayssir John Gabbour Send private email
Sunday, March 27, 2005
 
 
i might have been the developer that said the company i work for was consider building their own bug tracking/project tracking software.

indeed, this was something that was being considered. however, i don't think it will ever take wings.

So build vs. buy... in short, if a company wants to do project tracking a certain way and nobody else has what you want then build.
Patrick Send private email
Sunday, March 27, 2005
 
 
i've always been a fan of build - i'm a developer!

i agree with the general joel philosphy that don't build for the things that are your core business. I amend that to say "as long as a vendor can provide your desired funcationality".

why build? Because if you're good at building software (which few places are), then you build EXACTLY what you want.
Patrick Send private email
Sunday, March 27, 2005
 
 
Not to hijeck the thread or anything, but I wrote up a page on this for my product, attacking exactly this problem. I tried to focus it on management and to talk about "Return on Investment" and all that jazz.
http://www.ricebridge.com/products/csvman/roi.htm

About 1 in 50 visitors to my site read it. I guess that means it's not really as necessary as I thought.

Well, the main point of this post is that if you sell development software you should at least attempt to address this issue. I know that my customers are almost certainly developers who have to justify a purchase to their manager so I have to give them some ammunition.
Richard Rodger Send private email
Monday, March 28, 2005
 
 
God dammit Joel, give us a spell checker!
Richard Rodger Send private email
Monday, March 28, 2005
 
 
I'm thinking about this for my own product, which will be targeted at small development shops and individual programmers. When I look back at my consulting and corporate days, I never wanted the source code. I never had time to read and understand it -- did you ever look at the source code for Lucene? Simply finding a class with an actual implementation takes half a day. Which is sad, because I only had 1 day to make the fix I was looking for. (Although trust me, Lucene is awesome.)

I think what's more helpful is a simple, open, documented, and plaintext file format.  Maybe XML but not overdone. This lets people do what they need to do -- which is usually spooge the data into another system and work with it some more. Data exports are also important.

And a documented plugin architecture never hurts, but that seems like alot more work, for questionable return. Necessary for a UI builder, but maybe not so much for a Fixed Asset Manager.
Vineel Send private email
Monday, March 28, 2005
 
 
Richard Rodger,

  Spell Checker should never be a part of the web app, but rather should be a part of the web client. We don't need to figure out a new paradigm for spell checking on each site, and we don't need every screwed up dictionary on each site.

  On the client side, if you're using FireFox check out SpellBound (http://spellbound.sourceforge.net/install), among a variety of options. On IE there are a variety of options, none of which I have personal experience with (http://www.google.ca/search?hl=en&q=spell+checker+internet+Explorer&spell=1).
Dennis Forbes Send private email
Monday, March 28, 2005
 
 
"This is simply another sad example case of NIHS..."

I'd point out that an equally detrimental, and equally common, syndrome is "BNBIHS" - Better Not Be Invented Here Syndrome.

This is the tendency for empire building middle managers, rotating through the corporation looking for the point at which they're no longer incompetent, who petition for every inhouse application -- applications admirably doing their jobs and fulfilling their role with limited cost -- to be replaced by external vendor applications. This is most pronounced when some internally-built application is a big political "win" for someone they dislike or compete with.
Dennis Forbes Send private email
Monday, March 28, 2005
 
 
I don't understand RM's calculation above.

"Product X Total Cost Difference Ratio
Version 1.0: 1:20
..
Version 2.0: 1:14
..
As you can see, the gap is closing fast, if the company is just looking for the bug fixes but not new (useless) features."

I'm not convinced that this set of invented numbers is reasonable, and I don't see how you extrapolate a trend from 2 data points. Why will developing features for version 3.0 always be cheaper than upgrading to 3.0?

"A sad fact is the Buy camp usually assumes there is exactly ONE developer, therefore the cost difference appears LARGER than it actually is."

What difference does it make how many developers are involved? If a piece of software requires N person-hours to build and your employees cost $100 an hour you can estimate the cost of building it regardless of how many people actually work on it. Unless you're thinking of per-seat licenses, in which case the software is probably a significant piece of work and not worth trying to build anyway.

I am a developer, so I identify with the temptation to DIY. But, as others have pointed out, one needs to decide whether one wants to spend one's time building tools or doing the real work one set out to do.

As a company grows it becomes easier to divert man-power to build something rather than to try to get a new purchase approved, but it's still probably the wrong thing to do - if you think you can spare developers for something that only indirectly affects your core business you have more serious problems than this particular buy-build decision.

All this is modulo finding a good product to buy, where 'good' pertains to features ("Does it do 80% of what I want?") but more importantly to the vendor ("Am I getting locked into a specific format for my data? Is the vendor going to charge for bug-fixes? Force upgrades?")
Kartik Agaram
Monday, March 28, 2005
 
 
RM, you fail on one point: When you buy and you don't want any new features you don't have to buy. In your case the buy vs. build ratio will still be 1:20 since you're not going to upgrade to version 2.0.
Peter Monsson Send private email
Tuesday, March 29, 2005
 
 
I am not trying to prove the DIY is always favorable, however, I intend to point out that the BUY camp usually exaggerates the benefits more than it is.

Also, I did not say what Product X is; it could be anything from development tools to custom controls.  For the development build-buy decision, it is no question you should always buy unless your firm also produces a similar product.  (Read: Dog Food Eating) 

However, it is a little questionable to BUY custom controls (and such) for shrink-wrapped applications (not corporate business applications).  For instance, I doubt Joel or anyone else in his position, would have purchased the FogBugz Bayesian filtering or the “Four-click and a Drag”.  If they did, what is the competitive advantage?, if any competing products can also incorporate such products.

In addition, the BUY argument is usually so strong, there seems there is no place for the DIY camp for 99.99999% of the time, and then it will ultimately lead to Dennis Forbes’ BNBIHS. On the other hand, if you also look at any successful companies, they usually have more™ favorably opinion of DIY than BUY.

In summary, I usually give +10 bonus points to the DIY first then begin weighting pros and cons, if the product in question will be incorporated to the main product.  So the idea is, unless the BUY can make a case unequivocally™ - must go beyond simple monetary cost analysis, I go with the DIY.
RM Send private email
Wednesday, March 30, 2005
 
 
I think it depends on the stability of the functional requirements. For example, if your in-house app has to support the whims of your over-active marketing dept (e.g. a system to support your customer policies, if you're an insurance company), no amount of bought-in IT-ware is going to be able to fit the bill. But if the requirement is well-understood and static (e.g. an accounting system), then surely buy-in is the better solution.

App vendors will use 3rd-party functionality if it's not seen as a competitive advantage to develop it themselves (and also if the functional requirement is static, as above). Either way, the cost of using 3rd-party functionality or building it oneself should be factored into the price of the app to protect the ROI.
Paul Sharples
Wednesday, March 30, 2005
 
 
"In addition, the BUY argument is usually so strong, there seems there is no place for the DIY camp for 99.99999% of the time, and then it will ultimately lead to Dennis Forbes’ BNBIHS."

I don't think so. Preferring buy to build doesn't mean going out of one's way to fix what's not broken. If something's already Done Yourself, leave it be. Unless it's going to continue to suck up resources..

Ok, I see the grey area, the potential for politically motivated arguments :)

***

"For instance, I doubt Joel or anyone else in his position, would have purchased the FogBugz Bayesian filtering or the 'Four-click and a Drag'."

How realistic is this sort of 'product'? I haven't really seen it before.
Kartik Agaram
Thursday, March 31, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz