Computing On The Edge - 202341

Build vs Buy

Some developers have a strong bias towards action: you sense a need, and then start building.

I appreciate that sometimes ready-made solutions are available, and of good quality. On the latter, you cannot just assume: you need to assess somehow.

If my solution depends on some library solving the problem for me, the story might just not be over. That library might evolve, have security issues.

The minute you start depending on some library, you are going to adopt it and start caring exactly like if it were your own.

Most of the times it's fine. Some others, the problem that an arcane dependency seems to solve for you in a way that you don't fully grasp, might just not be worth it.

And we are back: instead of buying in a solution, it would have been better to build, and understand.

Developers in some areas, specifically those building customer-facing features are understandably more inclined to buying in ready-made solutions.

The customer wants a sleek interface, the UX person is pushing for a better experience, and declining would put you in a difficult spot.

But this is exactly how you start using fonts that are in reality trackers, remote calls where there is no need, and depend on plain huge amounts of business code that you are never going to find the time to assess and see the implications.

This space is governed by bad incentives: once you get into the talk, you start losing.

We must find some better way. Building more could be one, probably not in absolutely every context, but building teaches you your weaknesses, while the product you buy makes its best to hide them from you.

Reading Tips for the week

Distributed Computing

Simulating Network Conditions with Traffic Control

Reasons Why Bare-Metal Clouds Could Be Next Big Thing in Cloud Computing

The Way To Go

Introduction to CORS for Go programmers

---

[security]