Hacker News Reader

Comment by eikenberry | Hacker News Reader

> Use off-the-shelf programs & libraries. Delete all your custom stuff. Replace good solutions with "good enough" solutions.

Be very careful following this advice. Only use an off-the-shelf if it is pretty close to what you need or if you can change the need to fit the tool. Trying to shoehorn processes (or whatever) that don't fit a tool to a tool often end up being a lot worse than a custom coded solution. I've seen this multiple times at enterprises that preferred vendor solutions as you suggest and they were worse train wrecks than places that used more custom solutions.

View on HN

The best way I've heard this put to me was this: "Your business has some special selling point where it stands out, the reason it's unique and people should buy your thing. Your business has hundreds of bog standard things it needs to do. You only have so much development time; spend it on the stuff that makes your company important and not on the stuff that already has perfectly good solutions sitting on the shelf."

Very true, but I've also seen the inverse where days were spent on configuring and troubleshooting an off-the-shelf solution (with associated technical debt around upgrades) where a small in-house ad-hoc process could solve it much easier.

The answer is not always obvious and being able to make the right call consistently is something I consider a sign of a great engineer.

Yup, this is the version that makes sense to me, with one addition:

If a component is high cost, tightly integrated with the rest of the system you're building, and difficult to design, you will need to become an expert on it just in order to evaluate suppliers and make good purchasing decisions.

Then (a) In order to become an expert on something, you need to do it yourself for a while; and (b) if you're an expert on it and have made it for a while, you might as well continue.

Thus: for high cost, tightly integrated, difficult to design parts: build, don't buy.

If a component is a major part of the value you're providing, it's sort of the same situation: you need to be an expert on it to safely buy it, and then you might as well build it indefinitely.

> Your business has hundreds of bog standard things it needs to do. You only have so much development time [...]

True for startups. Not true for BigCo. Economically it's a balance between the cost of a dev customizing the cogwheel and the cost of pushing the organization toward a standard factory-made cogwheel.

Manager: We need API gateway and Service Mesh in Kubernetes for our service

Engineer: I have come up with solution that wouldn't need all these frameworks.

Manager: Good. See how soon you can integrate with API Gateway and Service Mesh.

Heard at friend's workplace.

Question is, was it use AN api gateway or use THIS api gateway.

It was use THIS api gateway.

Mainly it was exercise in moving from technical work to year long vendor negotiation and setup. The OTHER API gateway blew up despite being used at Netflix. But THIS one is NextGen® so obviously much better.

Without more context either party could be in the wrong there.

- The developer for building a non-standard solution that wasn’t asked for and is impossible for the next person to maintain (like those who decide to roll their own database, VCS, encryption, etc)

- or the manager for not understanding the requirements of the build and then expecting developers to redo existing work rather than spending 5 minutes learning the tech stack.

Either way, this is why some orgs refuse to allow any development without a technical design. When you go into a build with a design that everyone agrees on you ensure that expensive development time is focused and less time is wasted rewriting code due to missing requirements.

> expensive development time is focused

Is development time all that expensive? Compared to time spent making different designs.

This is also something I've experienced a lot in large orgs. Having 10 developers +2-3 managers have weeks of endless discussions, design work being done to avoid "costly" development.

Sure developer time is costly, but developers in meetings and design rounds are just as costly if not more so, because more people are involved.

This then gets exacerbated when after weeks of discussion and design an attempt is made to implement an MVP where it is noticed that none of the decisions made work very well for this particular use case.

You can of course face the opposite problem of not designing and implementing something wrong.

This is why I always ask to make a small test first. say you have 5 possible rendering backends for your graphical output, where you don't know which one to use. Spend some developer time building a miniature test to see if the features are there for each one. Often as soon as you start using it you can rule 1 or two out after a few minutes. (Installation breaking). The rest you can sort out in a few hours by modifying the examples they use on their web page.

This often leads to only 1 or 2 actual possibilities, focusing the ensuing design work on what matters.

Who says the developer was building a non-standard solution? I read it as they would use one tool instead of the few that the manager suggested.

The key in using off-the-shelf software, especially if you're not a capital-E Enterprise that can dictate new features, is to be willing to change your business processes so that they match the tools you're buying. Part of the purchasing process for SMBs should be (but almost never is), evaluating current processes, and which parts of those processes are arbitrary and/or can be changed, then finding COTS software that fits all the must-have/can't-change processes. Then you adjust the last few remaining things to fit the software.

That works for the first tool you buy.

But invariably you continue to follow the advice and buy a 2nd. And it won't integrate well with the first. By the time you get to the 10th system that doesn't want to talk to the others, you're employing dozens of people to do the data entry between them.

And these proprietary systems almost _never_ want to talk to the others. There is a reason Outlook doesn't talk to Google Calendar, and Google doesn't talk to outlook's calendar, yet somehow Thunderbird (open source) manages to talk to both. And I can't count the number of times Microsoft has managed to break their IMAP interfaces.

I've seen this dark pattern in so many large businesses now, I've come to believe it's the norm.

My O365 displays my Google calendars just fine. My iOS and macOS calendar apps display both just fine.

I use a handful of Google calendars, but almost never use the Google calendar UI directly and interact almost exclusively via the Apple or Microsoft UIs to the Google store of data. (As in I might use the Google UI directly perhaps once a year, and that's generally only to get the access/path to the iCal interoperability URL.)

I worked at one place that had the worst of both worlds: SAP Hybris, customized to the nth degree with rushed features.

It was pretty awful and had significant, material negative impacts on revenue due to all the operational issues.

> worst of both worlds: SAP Hybris, customized to the nth degree

I've observed that nearly every customizable "off-the-shelf" solution will eventually converge to this end-state: dozens or hundreds of ad-hoc modifications to support an entrenched business process that incidentally makes upgrades nearly impossible. Non-customizable off-the-shelf software is rarely any better: all of the needed (or perceived needed) points of customization are managed outside of the software but rely on undocumented conventions.

See, basically any SAP integration.

Reply on news.ycombinator.com