🔥 Tech Blips #23.3
In this technology newsletter: Domain Storytelling, Meilisearch, Qwik and Icepanel.
Latest
🔥 Tech Blips #23.2
In this technology newsletter: Architecture Characteristics Worksheet, Replay, D2 Diagram Scripting Language and Tauri.
🔥 Tech Blips #23.1
In this technology newsletter: Context Map (DDD), CodeScene, Elm and SuperTokens.
The Ultimate Guide To Software Architecture Documentation
This guide shows you how to write, structure, visualize and manage software architecture documentation in a lean way using appropriate documentation tools.
🔥 Tech Blips #22.12
In this technology newsletter: Architectural Fitness Function, Context Mapper, Spring Modulith and Gitpod.
Inspirational Technology Radar Examples
In this article you will find inspiring examples of different companies documenting their technology management with a technology radar and making the results public.
Which web frontend architecture fits best?
This post will help you find the right web frontend architecture that best fits your specific quality goals.
🔥 Tech Blips #22.7
In this technology newsletter: Documentation as Code, AsciiDoc and Asciidoctor.
What is Documentation as Code? And why do you need it?
"Documentation as Code" means that your documentation process benefits from the same techniques used in software development.
Why should you document your software architecture?
In this post, you'll learn why you should write and maintain software architecture documentation. I try to answer the question, which goals you pursue with the documentation of your software architecture and illuminate it from an economic point of view.
🔥 Tech Blips #22.6
In this technology newsletter: Monorepo, Nx, WebAssembly and Fly.io.
The Best Way to Deep Clone an Object in JavaScript
This post shows you several ways to create a deep copy of an object in JavaScript.
🔥 Tech Blips #22.5
In this technology newsletter: Four Key Metrics, ArgoCD, Testcontainers and GraalVM.
Hands-on: How a serverless architecture can work
This is a sneak peek of my learning project that shows how a serverless architecture can work with React, Supabase and Azure Functions.
🔥 Tech Blips #22.4
In this technology newsletter: Conventional Commits, Renovate, Chakra-UI and Azure Functions.
🔥 Tech Blips #22.3
In this technology newsletter: CUPID Properties, Jetbrains Space, Playwright and Bun
🔥 Tech Blips #22.2
In this technology newsletter: Architecture Decision Records, GitHub Copilot, Next.js and Vercel
Under the hood: Architecture and Technology Stack of Supabase ⚡
Supabase under the hood. This post shows you the high-level architecture and the technology stack of Supabase.
🔥 Tech Blips #22.1
In this technology newsletter: Diagram as Code, Structurizr, Solid and Supabase
What is NgRx and why is it used in Angular apps?
This post will show you what NgRx is and why it is used in modern Angular frontend architectures.
Step-by-step guide: Create an Impact Map using a real-world example
In this practical guide, you'll learn how to create an Impact Map for a specific business goal and get a template for your next impact mapping session.
Impact Mapping: Our Impact as an agile organisation
We often talk a lot about various initiatives and the resulting technical solutions in detail. But we often do so without keeping in mind the specific business objective and the desired impact we want to achieve. This is where Impact Mapping comes in.
Which Git merge strategy is appropriate for our team?
How do you make your feature development traceable and easy to read in your Git history? How do you keep your Git history clean? What is the best Git merge strategy for our team?
Do we need a software architect in our agile team?
This question often comes up in agile teams. In this blog post, we look for the answer to this question in the context of the various agile and organisational frameworks like Scrum, LeSS, SAFe, Disciplined Agile and draw a conclusion.
12 Principles of Agile Software Development
While preparing for my guest lecture on technology decisions, I stumbled across a slide with the 12 principles from the agile manifesto.
It made me realise again how apt these principles from the agile manifesto from 2001 (!), which are often forgotten in practise, are for product development.
What is Infrastructure as Code? And why do you need it?
This article describes what Infrastructure as Code is and what problems Infrastructure as Code can solve. We also discuss the benefits and challenges of Infrastructure as Code and which tools are suitable for Infrastructure as Code.
Technical Debt Scenario #5: The code documents the system.
Unfortunately, several long-time developers have left the product team. In addition, there is virtually no technical documentation for the system. Even the architectural decisions are no longer traceable. What would you do to eliminate this kind of technical debt?
Technisches Schulden Szenario #5: Der Code dokumentiert das System.
Leider haben einige langjährige Entwickler das Produktteam verlassen. Zusätzlich gibt es praktisch keine technische Dokumentation zum System. Auch die Architekturentscheide sind nicht mehr nachvollziehbar. Wie würdest Du vorgehen eine solche Art von technischen Schulden zu adressieren?
Technical Debt Scenario #4: Hype Driven Development
The development team is always on the hunt for the latest technology hype. Currently, there are more than two front-end frameworks used for the product and the time to launch new features is getting longer and longer. What would you do?
Technisches Schulden Szenario #4: Hype Driven Development
Das Entwickler Team ist ständig auf der Jagd nach den neusten Technologie-Hypes. Aktuell werden im Team bereits zwei unterschiedliche Frontend-Frameworks gleichzeitig eingesetzt und die Geschwindigkeit des Teams wird dadurch ausgebremst. Was würdest Du tun?
Technical Debt Scenario #3: I don't care about the product.
The development team works too fast and breaks things. You find that they do not care about the product at all. What would you do about it? And how can you prevent the resulting technical debt?
Technisches Schulden Szenario #3: Ich interessiere mich nicht für das Produkt.
Das Entwicklerteam arbeitet zu schnell und es werden ständig bestehende Funktionalitäten gebrochen. Du nimmst wahr, dass es die Entwickler nicht wirklich interessiert. Was würdest Du dagegen tun? Und wie verhinderst Du die daraus resultierenden technischen Schulden?
Technical Debt Scenario #2: Feature factory
Your stakeholder wants to see features at an impossible speed. Your team's velocity is dropping due to technical debt, so sometimes the product owner or another stakeholder says, "I do not understand why it's taking so long to add a new feature." What do you say then?
Technisches Schulden Szenario 2: Die Feature Fabrik
Deine Stakeholder erwarten, dass Du mit deinem Team neue Features in einer unmöglichen Geschwindigkeit entwickelst. Irgendwann kommt ein Stakeholder und sagt Dir: "Ich verstehe nicht warum es so lange dauert dieses eine neue Feature zu entwickeln. Das sollte doch einfach sein." Was sagst Du dann?
Technical Debt Scenario #1: Start without any architectural vision
The team is working on a new software product. The only thing the team wants is to start coding. How can technical debt already cause?
How would you describe technical debt to a non-technical person?
If you work on a product team, you'll come into contact with people who don't have a technical background. One day, that person will ask you what technical debt is. That's your opportunity.