Even as whistleblowers continue to reveal misgivings at Facebook, the social media company is keen to enter the next phase of its growth and rebrand the company image to reflect its scale and its vision.

Rebranding of the company is not new in the tech world. While Snapchat shortened itself to Snap in 2016, a year earlier, Google reorganized itself under the brand ‘Alphabet’ to drop the tag of a ‘search engine company’ and focus on ambitious projects outside the digital realm as well. Facebook’s attempt looks similar to Google’s approach and more details are likely to emerge in about a week, as the company converges for its annual Connect Conference on October 28th.

But the main question is, will the values change?

Find out more at https://bit.ly/3aRqnmN

#engineering

Platform Engineering

I spent several years working in a platform team, and I was really surprised by hype around the field over past year. So I decided to understand why platform engineering has become so popular and what is really meant under that nowadays.

According to Wikipedia:

Platform engineering is a software engineering discipline that focuses on building toolchains and self-service workflows for the use of developers. Platform engineering is about creating a shared platform for software engineers using computer code.

Sounds simple. But what problem does it solve?

Over the last 2-3 decades, the complexity of software development significantly increased. Developers should understand CI\CD pipelines, know how to work with Kubernetes and its components, integrate with public cloud services, incorporate scaling strategies and observability tools. This complexity increases cognitive load and slows down the delivery of business features. Introducing dedicated platform teams should help shift the focus of product and delivery teams back to implementing business features.

So what platform teams actually do (of course, nobody can do everything and specialization is required):
✏️ Help developers to be self-sufficient: prepare started kits, IDE plugins, "golden path" templates and docs, self-service APIs
✏️ Encapsulate common patterns and practices into reusable building blocks: identity and secret management, messaging, data services (including databases, caches and object storages), observability tools, dashboards and code instrumentation approach
✏️ Automate build and test processes for products and services
✏️ Automate delivery and security verification processes for products and services
✏️ Accumulate expertise about underlying tools and services, optimize their usage
✏️ Provide early advice and feedback on problems or security risks

Platform engineering principles:
✏️ Adopt a product mindset: take ownership of the platform, make it attractive for developers to use
✏️ Focus on user experience
✏️ Make platform services optional and composable: allow product teams to use only the parts of the platform, or replace them with their own solutions when necessary.
✏️ Provide self-service experience with guardrails:  empower development teams to make their own decisions within a set of well-defined parameters
✏️ Improve discovery of available tools, patterns and templates
✏️ Enforce automation and everything as a code approach

Since the publication of the CNCF Platform White Paper in 2023, the popularity of platform engineering is still growing. In 2024, there was even a dedicated conference—Platform Conf' 24—highlighting huge interest and importance of the discipline.

Summing up, platform engineering is a powerful pattern to reduce cognitive complexity of application development, speed up business features development, and provide a more reliable and scalable infrastructure.

References:
- CNCF Platforms White Paper
- Google Cloud: How to Become a Platform Engineer
- Microsoft: What is Platform Engineering

#engineering

Inżynieria Platformowa

Przez kilka lat pracowałem w zespole platformowym i byłem naprawdę zaskoczony szumem wokół tej dziedziny w ciągu ostatniego roku. Postanowiłem więc zrozumieć, dlaczego inżynieria platformowa stała się tak popularna i co tak naprawdę kryje się pod tym pojęciem w dzisiejszych czasach.

Według Wikipedii:

Inżynieria platformowa to dyscyplina inżynierii oprogramowania, która koncentruje się na budowaniu łańcuchów narzędzi i samoobsługowych przepływów pracy do użytku programistów. Inżynieria platformowa polega na tworzeniu wspólnej platformy dla inżynierów oprogramowania przy użyciu kodu komputerowego.

Brzmi prosto. Ale jaki problem rozwiązuje?

W ciągu ostatnich 2-3 dekad złożoność rozwoju oprogramowania znacznie wzrosła . Programiści powinni rozumieć potoki CI\CD, wiedzieć, jak pracować z Kubernetes i jego komponentami, integrować się z publicznymi usługami w chmurze, włączać strategie skalowania i narzędzia obserwowalności. Ta złożoność zwiększa obciążenie poznawcze i spowalnia dostarczanie funkcji biznesowych . Wprowadzenie dedykowanych zespołów platformowych powinno pomóc przesunąć nacisk zespołów ds. produktów i dostaw z powrotem na wdrażanie funkcji biznesowych.

Czym więc tak naprawdę zajmują się zespoły platformowe (oczywiście nikt nie potrafi robić wszystkiego, dlatego wymagana jest specjalizacja):
✏️ Pomoc programistom stać się samowystarczalnymi: przygotuj zestawy startowe, wtyczki IDE, szablony i dokumenty „złotej ścieżki”, interfejsy API samoobsługowe
✏️ Utrwalanie powszechnych wzorców i praktyk w postaci wielokrotnego użytku bloków konstrukcyjnych: zarządzanie tożsamościami i tajnymi informacjami, przesyłanie wiadomości, usługi danych (w tym bazy danych, pamięci podręczne i magazyny obiektów), narzędzia do obserwacji, pulpity nawigacyjne i podejście do instrumentacji kodu
✏️ Automatyzacja procesów tworzenia i testowania produktów i usług
✏️ Zautomatyzuj procesy dostarczania i weryfikacji bezpieczeństwa produktów i usług
✏️ Gromadź wiedzę specjalistyczną na temat podstawowych narzędzi i usług , optymalizuj ich wykorzystanie
✏️ Udzielaj wczesnych porad i informacji zwrotnych dotyczących problemów lub zagrożeń bezpieczeństwa

Zasady inżynierii platformowej:
✏️ Przyjmij nastawienie produktowe: przejmij odpowiedzialność za platformę, spraw, aby była atrakcyjna dla programistów
✏️ Skup się na doświadczeniu użytkownika
✏️ Zadbaj o to, aby usługi platformy były opcjonalne i możliwe do komponowania: zespołom produktowym pozwól korzystać wyłącznie z części platformy lub w razie potrzeby zastępować je własnymi rozwiązaniami.
✏️ Zapewnij obsługę samoobsługową dzięki zabezpieczeniom: pozwól zespołom programistycznym podejmować własne decyzje w ramach zestawu ściśle zdefiniowanych parametrów
✏️ Poprawa odkrywania dostępnych narzędzi , wzorców i szablonów
✏️ Wdrażaj automatyzację i wszystko jako podejście oparte na kodzie

Od czasu opublikowania CNCF Platform White Paper w 2023 r. popularność inżynierii platformowej nadal rośnie. W 2024 r. odbyła się nawet specjalna konferencja — Platform Conf' 24 — podkreślająca ogromne zainteresowanie i znaczenie tej dyscypliny.

Podsumowując, inżynieria platformowa to skuteczny wzorzec, który pozwala na redukcję złożoności poznawczej procesu tworzenia aplikacji, przyspieszenie opracowywania funkcji biznesowych oraz zapewnienie bardziej niezawodnej i skalowalnej infrastruktury.

Odnośniki:
- Biała księga platform CNCF
- Google Cloud: Jak zostać inżynierem platformy
- Microsoft: Czym jest inżynieria platformowa
♨️https://t.me/ProgramowanieLinux/1559
#engineering #PlatformEngineering

GenAI for Legacy Systems Modernization

While most people actively write about using GenAI tools to generate new code, there is a new Thoughtworks publication that focuses on the opposite — using AI to understand and refactor legacy systems.

What makes legacy systems modernization expensive?
- Lack of design and implementation details knowledge
- Lack of actual documentation
- Lack of automated tests
- Absence of human experts
- Difficulty to measure the impact of the change

To address these challenges Thoughtworks team developed a tool called CodeConcise. But the authors highlighted that you don't need exactly this tool, the approach and ideas can be used as a reference to implement your own solution.

Key concepts:
✏️ Treat code as data
✏️ Build Abstract Syntax Trees (ASTs) to identify entities and relationships in the code
✏️ Store these ASTs in graph database (neo4j)
✏️ Use a comprehension pipeline that traverses the graph using multiple algorithms, such as Depth-first Search with backtracking in post-order traversal, to enrich the graph with LLM-generated explanations at various depths (e.g. methods, classes, packages)
✏️ Integrate the enriched graph with a frontend application that implements Retrieval-Augmented Generation (RAG) approach
✏️ The RAG retrieval component pulls nodes relevant to the user’s prompt, while the LLM further traverses the graph to gather more information from their neighboring nodes to provide the LLM-generated explanations at various levels of abstraction
✏️ The same enrichment pipeline can be used to generate documentation for the existing system

For now the tool was tested with several clients to generate explanations for low-level legacy code. The next goal is to improve the model to provide answers at the higher level of abstraction, keeping in mind that it might not be directly possible by examining the code alone.

The work looks promising and could significantly reduce the time and cost of modernizing old systems (especially written on exotic languages like COBOL). It simplifies reverse-engineering and helps generate knowledge about the current system. The authors also promised to share results on improving the current model and provide more real life examples for the tool usage.

#news #engineering #ai

Software Complexity

Have you ever seen a project turned into a monster over time? Hard to understand, difficult to maintain? If so, I highly recommend Peter van Hardenberg’s talk - Why Can't We Make Simple Software?

The author explains what complexity is (it's not the same as difficulty!), why software gets so complicated, and what we can actually do about it.

Common reasons for complex software:
✏️ Defensive Code. Code that starts simple with implementing some sunny day scenario but grows over as more edge cases are handled. Over time, it turns into a mess with too many execution paths.
✏️ Scaling. A system designed for 100 users is really different from one built for 10 million. Handling scale often adds layers of complexity.
✏️ Leaky Abstractions. A well-designed interface should hide complexity, not expose unnecessary details. (A good discussion on this is in Build Abstractions not Illusions post).
✏️ Gap Between Model and Reality. If a software model isn't actually mapped to the problem domain, it leads to growing system complexity that really hard to fix.
✏️ Hyperspace. Problem can multiply when a system has to work across many dimensions—different browsers, mobile platforms, OS versions, screen sizes, and more.

The software architecture degrades over time with the changes made. Every change can introduce more complexity, so it’s critical to keep things simple. Some strategies to do that:
✏️ Start Over. Rebuild everything from scratch. Sometimes, it is the only way forward if the existing architecture can't support new business requirements.
✏️ Eliminate Dependencies. Less dependencies the system has, the easier it is to predict system behavior and make impact analysis.
✏️ Reduce Scope. Build only what you actually need now. Avoid premature optimizations and "nice-to-have" features for some hypothetical future.
✏️ Simplify Architecture. No comments 😃
✏️ Avoid N-to-M Complexity. Reduce unnecessary variability to limit testing scope and system interactions.

Complexity starts when interactions appear. So it is about dynamic system behavior. Watching this talk made me reflect on why systems become so complex and how I can make better design decisions.

#architecture #engineering

Dokumentacja jako kod

Jestem naprawdę przekonany, że dokumentacja jest częścią aplikacji . Powinna być rozwijana, aktualizowana i sprawdzana przy użyciu tych samych procesów i narzędzi, co kod aplikacji.

Jeśli dokumentacja jest przechowywana gdzie indziej, np. na oddzielnej wiki , to w zasadzie przestaje być aktualna w ciągu 5 minut od opublikowania .

Oznacza to, że dokumentacja powinna znajdować się w repozytorium git. Jeśli jakieś zachowanie systemu zostanie zmienione podczas naprawiania błędów lub opracowywania nowej funkcji, odpowiednia dokumentacja powinna zostać zaktualizowana w tym samym PR. Takie podejście pomaga utrzymać dokumentację na bieżąco .

To naprawdę proste, jeśli używasz monorepo . Wszystkie dokumenty i kod są umieszczone w jednym miejscu, więc łatwo znaleźć to, czego potrzebujesz. Rzeczy stają się bardziej skomplikowane, jeśli masz wiele mikrorepo . Nawet jeśli dokumenty są aktualne, użytkownikom trudno je znaleźć. Zwykle rozwiązuje się to, publikując dokumenty w centralnym portalu jako część procesu CI lub obecnie, korzystając z bota AI, który pomaga.

Niedawno Pinterest opublikował artykuł o tym, jak przyjęli podejście dokumentowania jako kodu . Ponieważ używają mikrorepozytoriów, głównym wyzwaniem było uczynienie dokumentacji możliwą do odnalezienia dla ich użytkowników w setkach repozytoriów.

Co zrobili:
🔸 Przeniesiono ich dokumenty do repozytoriów git, korzystając z języka znaczników Markdown.
🔸 Wykorzystano MkDocs w CI do wygenerowania wersji HTML dokumentów.
🔸 Utworzono centralne miejsce do przechowywania i indeksowania dokumentów o nazwie PDocs (Pinterest Docs).
🔸 Zintegrowana dokumentacja z GenAI — botem AI połączonym z głównymi kanałami komunikacji firmy.
🔸 Zbudowałem narzędzie umożliwiające migrację starych stron wiki do gita za pomocą jednego kliknięcia.

Nie znam żadnego standardowego rozwiązania dla agregacji dokumentów w wielu repozytoriach, więc byłoby wspaniale, gdyby Pinterest w przyszłości udostępnił swoje PDocs jako open-source. Myślę, że mogłoby to naprawdę pomóc wielu zespołom w ulepszeniu procesów dokumentowania.

#engineering #documentation
👇🏻👇🏻👇🏻👇🏻👇🏻

Documentation As a Code

I have a really strong opinion that the documentation is part of the application. It should be developed, updated and reviewed using the same processes and tools as the application code.

If the documentation is stored somewhere else, like in a separate wiki, it's basically dead within 5 minutes after it's published.

This means documentation should live in the git repo. If some system behavior is changed during bugfixing or a new feature development, the relevant documentation should be updated in the same PR. This approach helps to keep documentation up to date.

It's really simple if you use a monorepo. All docs and code are placed in one place, so it's easy to find what you need. Things become more complicated if you have lots of microrepos. Even if docs are up to date, it's quite hard for users to find them. Usually, this is solved by publishing docs to a central portal as part of the CI process, or nowadays by using an AI bot to help.

Recently, Pinterest published an article about how they adopted the documentation-as-code approach. Since they use microrepos, the main challenge was to make documentation discoverable for their users across hundreds of repos.

What they did:
🔸 Moved their docs to git repos using markdown.
🔸 Used MkDocs in CI to generate HTML versions of the docs.
🔸 Created a central place to host and index docs called PDocs (Pinterest Docs).
🔸 Integrated docs with GenAI — an AI bot connected to the main company communication channels.
🔸 Built a one-click tool to migrate old wiki pages to git.

I don’t know any standard solution for doc aggregation across multiple repos, so it would be great if Pinterest open-sourced their PDocs in the future. I think it could really help a lot of teams to improve their documentation processes.

#engineering #documentation