When I learned about TDD it boosted my productivity as a developer and made my professional life easier. By following this simple cycle, I was able to efficiently and effectively transform specifications into working software in an iterative manner. I’ve always wondered if there is something that supports the learning process in the same way, knowing it is also a crucial part of my job. As my career progressed, I accumulated practices that helped me speed up my learning. However, it wasn’t until I read the book “Get Better at Anything” by Scott H. Young that all the pieces fitted into a picture that worked for me: the Learning Loop.
[Read More]Neueste Events
- 10.02.21 The C4 Test Pyramid, OOP
- 27.09.20 Consumer Driven Contracts mit Openapi, JCON
- 20.02.20 Fix my TDD, Frankfurter Entwicklertag
Developer's Guide to Software Estimation
Episode II: Key Elements
The first article in this series covered the basics of software estimation and concluded that a systematic approach is preferable to wild guesses. But what are the key elements that make up a profound forecast, and how do they work? Those are the questions we will address in this article.
[Read More]Developer's Guide to Software Estimation
Episode I: The Basics
Getting asked about estimations was my worst nightmare when I started my career as a software engineer.Writing software was easy for me because I was familiar with design patterns, architecture styles, and principles in software engineering. But when it came to giving a forecast for a new project, I was lost. Where should I start? Where should I end? What principles should I follow and what methods can I use? To make matters worse, there were high expectations for a sound estimate. It was often crucial to the profit of my company. But how can I provide a forecast that meets all expectations and is profound at the same time?
After many years of reading articles and books on this topic and experimenting with different approaches, I came up with 10 basic tips that help me with this challenge. Here is what I’ve learned so far.
[Read More]Service Level Management the DevOps Way
Service Level Indicators and Objectives in Action
With the shift to DevOps product teams take responsibility for the overall reliability of a system. As a consequence they need a service level management that goes beyond merely measuring the availability and uptime of servers. Service Level Indicators and Objectives help them to achieve this by specifying and monitoring reliability from a user perspective. Together with methods from software architecture and domain driven design this approach can be seamlessly integrated into the accustomed development process.
[Read More]DDD Value Objects
Implementation Patterns for Kotlin
It is exciting for me to learn a new programming language, since it provides me with the opportunity to solve common programming problems more efficiently. In my primary area of work, back office business applications, Domain Driven Design (DDD) is widely used. So, when I switched from Java to Kotlin, I was curious to see how my new main language applies to these patterns . My first step was to learn about implementation alternatives of value objects, a concept for modelling data in DDD.
[Read More]Event Storming Notation explained
Your process as a sequence of state transitions
In learning about event storming, the hardest part for me was memorizing the order in which the different card types appear along the time line. As a result, I usually carried a cheat sheet like this with me.
I was bothered by its logic, however. It took me a while to figure out what it was about. I was able to make sense of it only after following the design process step by step for the first time. I would like to share this experience with you in this article by looking at an online shop’s order process.
[Read More]How to write an Architecture Decision Record
The ADR process in a nutshell
Architecture Decision Records (ADRs) are not only a great way to keep track of the choices you make while evolving your product architecture. It also guides you and your team through the decision process when you face new architectural challenges.
[Read More]Release Rollback
Zurück auf Anfang
Trotz aller Tests im Vorfeld lassen sich Fehler im Release einer neuen Softwareversion nicht immer vermeiden. Zum Glück werden sie meist schnell entdeckt und lassen sich durch ein einfaches “Fix Forward” beheben. Leider gibt es aber Fälle, bei denen die Fehleranalyse sehr aufwändig und gleichzeitig ihre Auswirkung auf die Nutzbarkeit des Produktes gravierend ist. Man denke nur an Memory Leaks oder Dead Locks, die nicht nur durch klassische Tests vorm Deployment schwer zu erkennen sind, sondern in der Regel auch eine zeitaufwändige Ursachenforschung erforderlich machen.
Um in solchen Fällen die Einschränkungen für den Nutzer gering zu halten, liegt es nah, einfach wieder auf die vorherige Softwareversion zurückzugehen. Doch was so einfach klingt, ist in der Praxis oft mit Schwierigkeiten verbunden. Es gilt einmal mehr: “Everything comes with a price tag.”
[Read More]Risikomanagement in der Architekturarbeit
mit Transparenz Gefahren meistern
Softwareentwicklung ist nichts für Feiglinge! Als Entwickler wissen wir, was so alles schiefgehen kann in den Produkten, die wir bauen. Immer wieder gehen wir in der Entwicklung Kompromisse ein, sei es um Aufwände zu sparen oder aber schlichtweg, weil die technischen Mittel nicht ausreichen, um allen Anforderungen uneingeschränkt gerecht zu werden. Doch sind diese Schwachstellen unserer Software Architektur auch unseren Product Ownern bewusst? Schließlich sind sie es ja, die am Ende des Tages die damit verbundenen Risiken tragen müssen? Ein einfaches Risikomanagement in der Architekturarbeit kann hier die notwendige Transparenz schaffen.
[Read More]Test Pyramide und Testing Trophy
Freunde oder Gegner?
Ist die Testpyramide falsch und sollten wir lieber mehr Integration als Unit Tests schreiben, wie die alternative Test Trophy es vorsieht? Zeit für einen genaueren Blick auf diese beiden Teststrategien.
[Read More]