News for hackers. Stuff that matters.
Re:Build tools around workflows, not workflows around tools by cratermoon on Saturday August 22, 2020 @01:44PM (#24245765)
Years ago I analyzed the build vs. buy question and came up with a rule that I later found to be not so original: buy for parity, build for competitive advantage.

Most of any business is commodity stuff, typically things like HR, payroll, logistics, finance, security. Except if your business is one of those functions. Take Amazon's logistics for example. They aren't just any online retailer, they are the dominant online retailer in large part because they optimized the hell out of their logistics pipeline.

But if it's not your bread-and-butter, then yeah, go ahead and change your workflow to whatever COTS software you pick requires. You'll be fine. I worked for an insurance company, and they picked PeopleWare for their HR system and used commodity software tools for their actuarials. I worked for a very large shoe company they has SAP at the core of their (extremely complex) product lifecycle management system because their real business differentiator is their design and marketing.

That same insurance company had a customer sales pipeline tailored to a specific market – high-end professionals like doctors, lawyers, and similar – so they had custom software for that. That same shoe company had customized design and bill of materials systems so they could get their shoes to market quickly and globally.

Re:Build tools around workflows, not workflows around tools by jimkleiber on Saturday August 22, 2020 @05:55PM (#24247579)
I've been thinking a lot about the buy (or rent) vs build problem and one factor that keeps screaming at me is: who do I want to maintain it?

If my team or I want to maintain it, then build. If not, then buy/rent. I've built way too many things over the last few years only to realize again and again that things we build will need to be maintained by someone.

As you say, if it's a competitive advantage, then it makes sense for me to fix it, update it, adapt it, etc., otherwise it may be too costly to get distracted with maintaining it internally and easier to pay someone else to do that.

Re:Build tools around workflows, not workflows around tools by 908B64B197 on Saturday August 22, 2020 @03:01PM (#24246371)
I agree with your rule, but I would add something extra:

Only build if you have the talent to do so. Early on Amazon managed to attract serious tech talent to the company. That enabled them to build. If a company can't do that then it's better to buy no matter what.

Re:Build tools around workflows, not workflows around tools by cratermoon on Saturday August 22, 2020 @03:08PM (#24246440)
> Only build if you have the talent to do so

I would certainly hope that if the function is part of what differentiates the company competitively that they'd hire the talent. If they're trying to be the best "X" company and nobody who works there is any good at "X", they should fail. The dot-com era is littered with the graves of companies who thought that just having an idea was enough.

Re:Build tools around workflows, not workflows around tools by 908B64B197 on Saturday August 22, 2020 @04:03PM (#24246849)
And yet it's surprising how a lot of companies simply won't match offers or try to play games with CoL. Or worst, consider engineering a cost center when it's central to the business.
Re:Build tools around workflows, not workflows around tools by tomnipotent on Saturday August 22, 2020 @11:11PM (#24249227)
> nobody who works there is any good at "X", they should fail.

Except almost every software startup in the last three decades was started by folks that were not experts in the domain they eventually became successful in.

Re:Build tools around workflows, not workflows around tools by johnjj257 on Sunday August 23, 2020 @06:47AM (#24251001)
Citations needed
Re:Build tools around workflows, not workflows around tools by dpacmittal on Sunday August 23, 2020 @04:00AM (#24250376)
Did online shop software even exist when Amazon started?
Re:Build tools around workflows, not workflows around tools by mattacular on Sunday August 23, 2020 @07:52AM (#24251253)
I was going to say "yes!" but then I looked it up that Amazon actually launched before Ebay as a business. I don't remember actually using Amazon personally until the 2000s but they've been around since 1994, almost a year before Ebay. I'm struggling to think of any earlier online retailers who would have been building ecommerce software.
Re:Build tools around workflows, not workflows around tools by howlin on Sunday August 23, 2020 @12:40PM (#24253125)
Especially in the early days, the main competitors to online retail were catalogue services. I would think they have most business and logistics problems in common, minus running a web site.
Re:Build tools around workflows, not workflows around tools by EdwardMSmith on Sunday August 23, 2020 @04:11PM (#24254910)
The Internet Shopping Network launched before Amazon, but I doubt they wouldn't probably have considered licensing any of their platform.
Re:Build tools around workflows, not workflows around tools by teddyh on Sunday August 23, 2020 @12:36PM (#24253083)
> buy for parity, build for competitive advantage.

Yes. As Joel Spolsky put it in 2001:

“If it’s a core business function — do it yourself, no matter what.”

— Joel Spolsky, In Defense of Not-Invented-Here Syndrome: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...

Re:Build tools around workflows, not workflows around tools by cratermoon on Sunday August 23, 2020 @03:08PM (#24254434)
Joel was one of the voices that helped me understand that, while my analysis was useful for myself and the employer at the time, my conclusion was not an especially original insight.
Re:Build tools around workflows, not workflows around tools by jmole on Saturday August 22, 2020 @02:39PM (#24246208)
I'd call it "rent for parity", not "buy". If all you have is a license, it's effectively a rental - not a purchase.

Rent for parity, buy or build for competitive advantage.

Re:Build tools around workflows, not workflows around tools by scott_w on Saturday August 22, 2020 @03:26PM (#24246591)
In practice this isn’t a problem. Take a non-software example:

Driving instructors typically have their cars on a 3 year hire purchase then return instead of buying. Why? Way back when, my driving instructor actually bought one of the cars. 3 months later, the engine failed and it was out of warranty.

Because of that, he realised that paying a monthly fee meant he had no surprise failures, he returned the car just as the clutch was burning out (learner drivers don’t have great driving technique, weirdly enough), and had a fresh car every 3 years for new learners.

Re:Build tools around workflows, not workflows around tools by quesera on Saturday August 22, 2020 @03:52PM (#24246781)
Makes sense, but FWIW and IIRC, the terms of an ordinary car lease prohibit commercial use.
Re:Build tools around workflows, not workflows around tools by scott_w on Sunday August 23, 2020 @02:35AM (#24250059)
I don’t know the details but I’m assuming he’s using commercial lease hiring, or the U.K. rules are different. The mileage and wear and tear alone would mean he’d be unable to hide it.
Re:Build tools around workflows, not workflows around tools by gukov on Saturday August 22, 2020 @04:15PM (#24246934)
If it's for business use you should be able to expense it.
Re:Build tools around workflows, not workflows around tools by danielheath on Saturday August 22, 2020 @07:11PM (#24248032)
If it’s for your own business who do you send the receipt to?
Re:Build tools around workflows, not workflows around tools by stickydink on Saturday August 22, 2020 @10:54PM (#24249159)
The government
Re:Build tools around workflows, not workflows around tools by masklinn on Saturday August 22, 2020 @03:50PM (#24246768)
Yeah I've never heard anyone think a driving instructor car was a great buy, unless you like replacing basically every driving component which can fail. These cars have it rough. Especially manual. I'm surprised a driving instructor (of all people) would think of doing that without also wanting to do a full engine and transmission rebuild.
Re:Build tools around workflows, not workflows around tools by scott_w on Sunday August 23, 2020 @02:33AM (#24250050)
He told me his reasons but he put it down as an expensive lesson learnt.
Re:Build tools around workflows, not workflows around tools by voiper1 on Sunday August 23, 2020 @01:08AM (#24249666)
I don't think rental covers any and all failures.
Re:Build tools around workflows, not workflows around tools by scott_w on Monday August 24, 2020 @01:41AM (#24257806)
It’s not a rental, it’s hire purchase with a warranty, so the most common things that are going to fail are covered. Other things are just not that likely to fail in the first 3 years.
Re:Build tools around workflows, not workflows around tools by cratermoon on Saturday August 22, 2020 @03:00PM (#24246364)
Shows how long I've been around. I still think of commercial software as something you buy and own.
Re:Build tools around workflows, not workflows around tools by tomnipotent on Saturday August 22, 2020 @11:10PM (#24249222)
If you can't resell it, you don't own it. Do you have examples of commercial software that you were allowed to resell?
Re:Build tools around workflows, not workflows around tools by sireat on Sunday August 23, 2020 @03:04AM (#24250170)
There used to be a pretty big business in US of reselling expensive software licenses (think AutoCad etc). I remember Autodesk trying to stop it and not being able to which brings us to the current day.

Of course now that everything is under pay as you go SaaS model, that's out of window.

Still in Europe it is legal (http://curia.europa.eu/juris/document/document.jsf?docid=124...) and people do resell mundane licenses such as Windows.

Re:Build tools around workflows, not workflows around tools by Sharlin on Sunday August 23, 2020 @01:29PM (#24253571)
Pretty much everything was resellable in Europe at least. Used computer games especially were a fairly big thing.
Re:Build tools around workflows, not workflows around tools by contingencies on Saturday August 22, 2020 @02:27PM (#24246118)
Re:Build tools around workflows, not workflows around tools by cheez on Saturday August 22, 2020 @02:34PM (#24246167)
You said it better than I ever could have!
Re:Build tools around workflows, not workflows around tools by cratermoon on Saturday August 22, 2020 @03:09PM (#24246461)
I can't take credit for the phrase, only for being thoughtful enough in my early career to more-or-less work it out from first principles.