🔴 Trunk-based development—Engineering Culture

This week's agenda & recap of last week

👇 Note: 16:00 CEST is now the standard time. Sign up on the LinkedIn event to have it easily pop into your calendar. It will be recorded, but I suggest you join in live for the chat participation.

Please set an intention if you don’t want to miss it. Let us know you’re coming and put it on your calendar.

Agenda for the Live Stream

• Keeping TBD simple

• Minimum CD (continuous delivery)

• Working with the strengths of your team

Q&A, live discussion throughout the 90 minutes. Don't be shy!

Check your time: Some countries will start rolling daylight saving changes starting next week. The event local follows Paris/Berlin/Amsterdam time.

Last week’s stream on Refactoring x Full rewrite

🤔 Tech debt is not about the amount of effort already invested, but rather the cost of all the features that cannot be implemented in the future due to the difficulty of adding them.

💰 Refactoring can be a more cost-effective approach than a full rewrite because it allows for the maintenance of technical debt, making the addition of new features cheaper. It’s like restructuring a loan or mortgage. You change the terms to adapt to your current needs.

💭 The accumulation of technical debt can lead to a point where adding new features requires paying off the debt in one go, causing a loss of track and the need for analysis to manage the mess. This is the dreaded full rewrite—but often it results in just a partial system-wide refactor. To make matters worse, new features may be added to placate uncertain stakeholders.

🤖 Refactoring should be seen as an investment to make future feature development easier, separate from creating new behavior.

🚧 Refactoring and addressing adjacent areas of technical debt can help shrink and suffocate the problematic areas, allowing for smoother development and feature addition.

🔄 The Strangling Fig pattern allows for a gradual refactoring approach, slowly absorbing functionality from the old system into the new one, rather than doing a full rewrite.

💡 Many companies that resist rewriting their codebase may reveal poor professionalism and underlying problems with their architecture, technology, processes, or documentation.

💡 TDD forces developers to think about important considerations like asynchronous vs synchronous, direct vs callback based, and transaction boundaries early on in the code, leading to better learning and understanding throughout the process.

Adaptability and Agile Development

🤔 Not being able to adapt to change is the core problem, not change itself. This is a strong signal of poor product/platform engineering practices when it comes to software development. When it seeps into databases and data itself, it may be a sign that improvements in Data Engineering / ML culture are necessary as well.

📱 The market evolves quickly, and companies have a limited time to capitalize on a product before they need to build a new one that matches the expectations of what "better" means next year.

🔄 The idea of agile development is to maximize learning and defer commitment, admitting that you don't know what will perform well on the market.

💡 Changing requirements should be normal in software development, as software is meant to be changeable and adaptable unlike hardware or embedded systems.

🤔 "This idea that planning is more important than the plan itself...that's what agile is and a lot of organizations are not." - Pointing out the misconception that quick, rigid planning is more valuable than being agile and adaptable in development processes.