The Weekly Top 7 DEV Articles You Should Read (20/01 - 27/01)
Divert the Flow, Leaving Facebook, Tech Debt, Fixing Performance Regressions, Gemini is a Gem, Defense of Complicated Languages, Industry Knowledge.
1- Divert the Flow
In this article of the series: “Pattern of Legacy Displacement” in Martin Fowler’s blog is presented the “Divert the Flow” strategy, applied for decoupling upstream systems from critical Business Services. (20/01/2022)
https://martinfowler.com/articles/patterns-legacy-displacement/divert-the-flow.html
TL;DR:
A Critical Aggregator is a software component that aggregates data from various parts of the system to provide fundamental business information in a comprehensible form. It becomes an Invasive Critical Aggregator when strictly coupled with upstream systems, which are therefore unable to evolve independently.
The alternative at freezing upstream components until the Critical Aggregator is working is to apply a “Divert The Flow” strategy. The aim is simply to create a new implementation of the Critical Aggregator, decoupled from the upstream systems.
The first action for substituting this software component is to understand how it works. Data sources aggregation, together with user requirements should be well known and analyzed.
In this phase, it is common to discover unknown issues of existing business logic. The suggestion is to fix those issues right away otherwise the same workaround could be placed into the new component.
Once functionality has been re-established, a parallel run of the old and the new system could provide easier testing and a better go-live experience. Selective use of reconciliation tools could also generate alerts if old and new implementations start to diverge too far.
2- On Leaving Facebook
Alex Kotliarskyi writes about leaving one of the most important companies in the modern world. A story belonging to the movement of the Great Resignation. (21/01/2022)
https://frantic.im/leaving-facebook/
TL;DR:
The Motivations that brought him to leave Facebook, as one can imagine, are beyond salary, benefits, or social status.
Alex started working there in October 2012 in the golden era of the company. Exciting engaging projects one after the other. As the days went by, the initial magic was gone. Quality, craft, and focus weren’t as important as scale, metrics, and PSC. As the big corporation brought more politics, leadership changes, and reorgs into play, the motivation to leave grew stronger.
The journey to leave Facebook took Alex 3 months. He took this time to evaluate, analyze, and rethink his career. He deepened his knowledge about the IT market, IT companies, and himself.
After several applications and lots of time preparing for interviews, he ended up accepting an offer with roughly 70% of the money that he was making at Facebook. Work-life balance was not even in his parameter of choices as in Facebook he could get by barely working a few hours a day. Doing fulfilling work is more important than salary or work-life balance.
3- Tech Debt Explained to Everyone
Javier Lopez, Software Consultant Lead at Thoughtworks, writes about Tech Debt and how he categorizes it in four main types. (22/01/2022)
https://blog.devgenius.io/tech-debt-explained-for-everyone-2920fff97416
TL;DR:
Technical Debt it’s a metaphor explaining the generated complexity for system evolution introduced by defective software implementations.
It’s possible to categorize Technical Debt (TD) into four main categories:
Prudent deliberate TD: introduced by conscious decisions, taken to fasten implementations. It’s a good way to prioritize the development of critical business areas.
Reckless Deliberate TD: as in the previous case, it’s a conscious decision, but taken without a deep analysis of the consequences.
Prudent Inadvertent TD: introduced trying to discover the correct way of solving the problem during development.
Reckless Inadvertent TD: the result of pure uncertainty.
As it is very hard to measure, tasks that address the solutions of TD could not compete in importance with the development of new functionality. It’s possible to solve TD while working on other tasks, but usually, that's not enough.
It’s impossible to not introduce TD with new implementations. That’s why continuous refactoring and a specific developer’s focus are needed to maintain a healthy codebase.
4- Fixing Performance Regressions Before they Happen
This article presents the journey and the challenges that brought Netflix to the adoption of a very peculiar performance testing strategy. (24/01/2022)
https://netflixtechblog.com/fixing-performance-regressions-before-they-happen-eab2602b86fe
TL;DR:
Netflix needs to measure two main values: Memory (maximum used value) and Responsiveness (median value). Tests need to be executed pre and post-merge onto the main branch of the codebase.
Givin for granted that a real case scenario will always be different from a simulated one, the main challenge that Netflix has to overcome is the difficulty of defining the “failure” of a performance evaluation. Defining a static threshold does not suffice.
Netflix breaks the analysis of test results identifying two main singularities:
Anomalies (values major than a dynamic value: N multiplied for the standard deviation of the latest M tests, with N and M configurable values). An anomaly identifies a failure of the performance test.
Changing Points (values that identify a behavioral change in the series of tests). One changing point identifies implementation that can be further analyzed to check for regressions.
To decrease false positives and reduce noise, each test is executed three times, and the minimum value of the three is selected.
5- Gemini is a Little Gem
Gemini is a protocol of hypertext distribution. In this article, Andre Garzia addresses some criticism about it. (25/01/2022)
https://andregarzia.com/2022/01/gemini-is-a-little-gem.html
TL;DR:
Gemini is more than a protocol: it’s composed of many vibrant communities. Do not focus on protocol alone.
Gemtext (the syntax used to serve a Gemini resource) is just another Markdown: it’s easy for writers to use and for a computer to parse. Is biased towards textual content.
You can hold Gemini in your head: In comparison with the huge number of specifications of the Web, Gemini is really simple to implement and understand.
Constraints shine a spotlight on features: Gemini does not provide cookies or scripting. Simple markup it’s enough to provide users with documents. While it’s true that his privacy is not completely granted, its default configuration is still more private than the Web.
The replacement rhetoric is boring: users of Gemini do not want the Web to die. They just like to use this protocol.
Gemini is old-school-ish: old technology doesn’t mean that is bad. Old-school paradigms have their place. It’s boring, it fades into the background so that you can focus on what matters: the content.
Gemini is an exclusivist community: it enables those with older machines, retro computer enthusiasts, and many others to take part in a web-like experience.
6- In defense of complicated programming languages
The simplicity of a programming language is not always a plus. Jakob expresses his idea on the abstraction and complexities introduced by complex programming languages. (23/01/2022)
https://viralinstruction.com/posts/defense/
TL;DR:
When Jacob was learning for the first time about Classes in Python, he didn't grasp the concept. It's still possible to bypass classes and obtain the same results. That was because Classes or other constructs solve a peculiar problem: managing the complexity of code. If the project is simple enough, there is no need to introduce Classes.
A python with no classes will be simple! Consider anyway that if the project grows in complexity sufficiently, it's pretty sure that structure "classes-like" will emerge in the code.
The trend of using simple programming languages such as Zig is increasing lately. The point is that if we remove complexity from the programming languages themselves, we will end up moving the complexity elsewhere.
In the end, the choice is between introducing complexities yourself or using a specific functionality already provided by a complex programming language.
7- Does the software industry learn
Can we truly learn without considering the past? Tom Renner (24/01/2022)
https://www.tomrenner.com/blog/2022-01-24/does-the-software-industry-learn
TL;DR:
Institutional Knowledge is the information that a company collectively retains. It’s protected and valued. Institutional learning instead is the process of getting to know all the information needed to work in a company.
Many companies, especially smaller ones, try to optimize the process of acquiring institutional knowledge. What is difficult to track and optimize instead, is Industrial Knowledge.
Software developers thrive to learn new things. Industrial Learning is a huge part of our job, as we very often learn new frameworks or languages. But is this learning related to a more general-purpose Knowledge?
Usually, the new technology point-blank replaces the old. As new trends emerge, we thrive to remain on top without considering the past.
The problem is that learning should be built on top of a previous experience. It’s not common to find articles and comparisons looking back at past languages.
“We need more historians and librarians in our ecosystem and fewer blue-sky thinkers” for true knowledge could have a strong foundation only if it truly founders into the past.