Bradfield CS Blog

My head is nodding at the intention here, but it's important to remember this reactionary attitude can be damaging as well. That is missing from the post.

Specifically, reactionary conservatism about tools and services can be a competitive disadvantage.

In several workplaces I have seen this attitude co-mingle with pride in original code, and result in a counter-productive NIH (Not Invented Here)[0] attitude (reinventing wheels). Macho/heroism makes it worse.

While trend-following can be inefficient, if the engineers are both excited and humble and ready to weigh many trade-offs, this inefficiency might be "cheaper" than reinventing wheels for all problems.

Cue platitude: it takes balance :)

[0]: https://en.wikipedia.org/wiki/Not_invented_here

---------------------------------------------------------

EDIT:

To clarify I'm talking especially about _uninteresting problems,_ for which there may be an obvious off-the-shelf solution, such as when I've seen engineers invent a build system from scratch (and then cost _lots_ over years as that custom thing needs maintenance) ... when their needs could have been met by the language's standard tooling and using its plugin architecture.

Or, when "just use sticky notes and a whiteboard" gets so stubborn that a growing team stays in chaos for lack of organization.

On the other hand, it is quite bad when trend-following causes not just churn (switching tools), but overkill that introduces tons of cost and risk. i.e. distributed…

A lot of programmers talk about K.I.S.S (Keep It Simple Stupid) when it comes to writing their software but don't extend that to their build tools, or how they deploy it. Just like the "you are not google talk"^1 people tend to overengineer solutions for a problem they could have in the future. I'm certainly guilty of this. At work I can't just write some python code in an editor, I have to write and pass around Jupyter Notebooks. Or worse I have to launch a Jupyter Notebook inside a Docker container so that it loads the correct dependencies. I understand this is done to make things more reproducible but we've still had issues getting clients set up in our workflow even using this method.

I will be the first to admit I am a noob when it comes to systems programming, but I found it so frustrating when I attempted to learn C and C++ having to download and use Make, Cmake, Ninja etc, vcpkg, just to interface with other peoples code. And it was never just as simple as running the install script. A great example is Raylib on the PI4. The majority of Pis are running Raspbian/Raspberry PI OS and the only thing that changes between PI 4s is the amount of memory. So this should be the best case scenario for creating a install script. The raylib documentation says it should only require a couple Make commands. I ran them and it still failed.

I appreciate how D and Rust both have Cargo and Dub. While they have their warts, it makes it sooo much easier to link and install other…

Experience says no. Betteridge's law of headlines says no. I'm going with no.

But, given Conway's law, if you are a giant organization, then it probably meshes well with your organizational hierarchy, and you will use it regardless of whether it makes sense.

It probably does make sense if you are one of the few Big Tech companies working with trillions of transactions, since fault tolerance and scalability are paramount over absolute cost and maintability.

I worked on a "microservice" architecture at a very large firm using AWS Lambda. But it was entirely the wrong approach, and we were explictly forbidden from even implementing it in a textbook fashion. Would call it more of a hydra architecture - a term for this anti-pattern that I just made up - since it had a shared database. This is probably fairly typical.

And even though the organization was very large, it wasn't actually dealing with big data in any real sense, and you probably aren't either. You aren't Google. [1]

Luckily Infrastructure-as-Code is making it less terrible to do this, but it is still silly.

I think what they really wanted was a serverless architecture, but that could've been done as a monolith. With something like AWS Fargate you can have infrastructure-as-code and no server administration, and yet it will be a stateful always-on container.

[1] https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

Surprising and noteworthy are not the same thing, but pretending they are definitely lets you make your non-sequitur reply seem like it addresses mine...

It's noteworthy when tech projects are successful and simple, because in the industry there is a widespread tendency to try and replicate what "the big guys" are doing, and often times what they're doing is extremely convoluted.

In other words, it is significant when projects buck this trend, because it goes against the mistaken belief that the only way to be "web scale" to replicate some of the most complicated tech stacks out there, making it worth calling out. Significant being a synonym for noteworthy in case that needs to be clarified...

HN being an example of this doesn't somehow make every other example not noteworthy either if that was what you tried to say?

-

This concept has come up so many times I am, again, surprised anyone who is in the same tech industry as me does not realize it's a thing:

https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb?gi=9c2b0729a254

https://programmerfriend.com/not-google/

https://link.springer.com/chapter/10.1007%2F978-3-030-31646-4_13

Especially on Hacker News, a place where an immense amount of gnashing of teeth has happened over what the latest complicated tech stack that people convince themselves they need to make software that scales.

There are a number of blog posts by people such as Tim Bray, Steve Yegge, and others - as well as internal engineering blogs (at least there is one at Facebook and several at Google). I read these on a regular basis (Yegge's hasn't been updated in a while), but only to take away ideas and learn about new technologies.

Their approach is almost certainly not the right approach for you, because you are not Google ( https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb ). That said, if you are looking for a position at these places, then the blogs might help you, in a number of ways. If you want to work there though, focus on the sound engineering techniques applicable anywhere (maps, hashing, trees, graphs, algorithms) and build a reputation through Open Source contributions to the projects the companies are involved with.

* Tim Bray / Amazon / https://www.tbray.org/ongoing/

* Steve Yegge / Ex-Googler / https://steve-yegge.blogspot.com/ and https://medium.com/@steve.yegge

* Facebook Engineering Blog / https://code.fb.com/

* Google Developers Blog / https://developers.googleblog.com/

> How else would you scale to meet peak demand without being wasteful?

I can only speak to the banks I've have the opportunity to work with who stayed on prem or built their own internal cloud infra; what you call waste, they consider a premium/cost of business for security and resilience. I'm sure a lot of folks would've said the same thing about JIT supply chains (that had been squeezed to be as efficient as possible) until they unraveled.

> I don’t see how cloud’s advantages of scaling and worldwide “edge” locations can be replicated by the average bank’s tech team.

As always, "what are your requirements and what are you optimizing for?" Most folks don't need web scale nor edge locations [1] [2], they'll get by just fine with a CDN and some API endpoints [3].

[1] https://news.ycombinator.com/item?id=19576092

[2] https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

[3] http://mcfunley.com/choose-boring-technology