Live data from Hacker News

Buy Don't Build

jrott.com

91–100 of 227 posts

Re: Buy Don't Build

#91

All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.

In unreal and unity, most of the third party code I’ve tried to use ended up unusable because of either bugs, performance issues, or limitations. There are great exceptions but it’s been frustrating overall. The ones that do work, well, the documentation is often terrible and it takes longer to learn and integrate than it would to make your own. Finally, unity has a history of retroactively changing their terms of se…

unity (and maybe unreal) have a real problem in that the majority of users are hobbyists, students, and new programmers. None of them are really willing to pay much for 3rd party code and they need $$$$$$$$$$$$$ of support because they are new.

For example make a JSON serialization library and you'll be asked "how do I spawn enemies from JSON" which is arguably entirely orthogonal to your library but don't answer and get downvoted for bad support. Do answer and you'll just be asked more questions about how to adapt your example to their personal project and you'll have to teach them programming in the process.

These incentives make it almost impossible to make money selling 3rd party code (plugins/add-ons). If you charge what it should really cost given the amount of work put in the market won't bare it. If you charge what the market will bare you'll go broke.

Maybe Unity should split the market into "Pro" and "Hobbyist" and the Pro market would have prices more inline with what it actually costs. Check out the prices of libraries like Radgametools.com (you'll have to google the prices) for comparison.

Re: Buy Don't Build

#92

There are some good points in there, but it's worth noting build/deploying is becoming easier than ever. For a simple static site you could pay 300$ a website-builder-thing or you can build an app inside a docker container and your host will reboot it for you if it crashes. I use a docker-compose.yml file and I was able to quickly download an open source service that automatically renews my SSL cert. But yeah it depe…

good real-life example i just ran into: i host my own website, and now I want to run a newsletter/email campaign. I don't desire doing this work and it's cheeeaapp/free from certain services that guarantee high delivery.

Re: Buy Don't Build

#93
post #67

Earlier quoted context omitted.

I think you had great boss (assuming he did not start timer each time you stopped typing on keyboard). Those endless meetings become unproductive pretty fast. I suspect that in big part they become a self sustained cancer used to justify time and salaries of unproductive company members. As for the subject itself: frankly I do not see any advantage of hosting on say Azure over hosting myself. Either requires a good d…

> frankly I do not see any advantage of hosting on say Azure over hosting myself. In my opinion, cloud hosting only makes sense if your systems are architectured around being hosted on the cloud. If you can build your application in such a way that it runs in the free tier of serverless, then it's going to be considerably more cost effective than renting a dedicated server - but if you can't, then it absolutely won't…

>"If you can build your application in such a way that it runs in the free tier of serverless"

Serverless - that would be vendor/architectural trap. Besides free tier does not come anywhere close to be able to serve my applications. They serve real medium/big size businesses.

Re: Buy Don't Build

#94

These sorts of discussion always seem somewhat confused to me because "buying" vs "building" is not a binary choice. It is more often a choice between: 1. Buy some platform/framework which you will then need to hire a small army of costly consultants to integrate and customize for your particular business need. Or 2. "Build" your own solution by orchestrating a bunch of open source technologies to solve your problem.…

s/binary/simple/ ... and you're on to something.

Re: Buy Don't Build

#95
> It’s usually a major mistake, that ends up costing a ton of time and money

LOL this is hilarious. Because outsourcing to consulting firms (cough IBM cough) has never resulted in blow-outs and poor delivery.

Buying almost always means being trapped in a snake-oil contract that requires ongoing consulting costs that quickly outweight the costs of the actual software.

> This can be avoided by making sure that the key differentiators for your business are in-house.

Oh....so you are saying we should build now?

Blogpsam.

Re: Buy Don't Build

#96

All of this is true, but sometimes people forget that buying a solution doesn't mean there will be no work. Sometimes, the integration and maintenance of that integration ends up being more than building and maintaining your own solution, especially if you have to do any large changes to how your systems work in order to integrate.

In unreal and unity, most of the third party code I’ve tried to use ended up unusable because of either bugs, performance issues, or limitations. There are great exceptions but it’s been frustrating overall. The ones that do work, well, the documentation is often terrible and it takes longer to learn and integrate than it would to make your own. Finally, unity has a history of retroactively changing their terms of se…

Unity also changes their APIs around with every tiny version increment, meaning that any app store package has to be constantly on top of installing new versions of unity and updating all the little parts that break every week.

Re: Buy Don't Build

#97
Some people take lifetimes, even multiple reincarnations to come to the conclusion that they are buyers, not sellers. Some people are born marketers and are very good at persuasion, hyperbole, and other tools to sell a product/service.

Others are natural consumers: they develop tastes and grow to be rabid shoppers. It's good to sit in the middle of these two opposites, but often better to decide which extreme you want.

I know I've made the decision too late in life, when I wasted a vast portion of it trying to sell some product/service/idea when really I just wanted the latest Porsche!

Re: Buy Don't Build

#98
post #97

Some people take lifetimes, even multiple reincarnations to come to the conclusion that they are buyers, not sellers. Some people are born marketers and are very good at persuasion, hyperbole, and other tools to sell a product/service. Others are natural consumers: they develop tastes and grow to be rabid shoppers. It's good to sit in the middle of these two opposites, but often better to decide which extreme you wan…

I'm sure a lot of people would love to go all-in on the buy side. Where do you get the money to buy something if you don't sell anything though?

Re: Buy Don't Build

#99
This is Capitalist logic, and more specifically - an argument for the concentration of capital in the computing/IT sector.

We, software developers and users - people and small organizations - should adopt the opposite slogan:

Built, Don't Buy.

When we build, we improve our knowledge and understanding of systems. We help affect them, through engagement with their developers or through modification and forking. When the challenges and overhead of building exceed our abilities - this will drive us to:

1. Strive for better-fitting software - easier to use, deploy, build and maintain; and

2. Cooperate and collaborate with related organizations and communities/groups of developers and enthusiasts, either to share knowledge on how to get things done more easily, or to distribute the load of work between many parties, each of which can't do it on their own.

Even if a lot of FOSS contribution these days are made at for-profit corporations - the above is key to the future of both software freedom and social freedom.

Re: Buy Don't Build

#100
post #8
post #3

I'm totally on board with the overall message that building (i.e. engineering) your own internal tools come with lots of overhead, but take issue with this one point: > My counter-argument to that is there is also lock-in with internal systems. The most common version of this is the keeper of the spreadsheet. The author then disparages spreadsheets as becoming the exclusive domain of one employee who wouldn't want pr…

Author here I actually think spreadsheets are great because they are so accessible. What isn’t great though is when there is a business processs that is a spreadsheet and knowledge that exists in one persons head.

It is a management failure when this is in only one person head. Outsourcing tools will not solve internal management problems.
Post reply on HN