Probably every software developer had to estimate the effort needed to implement some wanted software. And the estimate was likely rather wrong. I collected reasons why this happened to me over many years. And I concluded that the estimation approach is fundamentally wrong. Here are my reasons:
Bi-temporal event sourcing combines storing data as a sequence of events, which tell what has happened with the data, and the data has two associated points of time, one when the data entered the system and one when the data takes effect. This post is about our 8+ years of experience with bi-temporal event sourcing, along with code samples showing how to achieve this. Feel free to skip the code blocks and just read the conceptual parts. But you’ll miss the beauty of F# 😂 This post is part...
This blog post is the written form of my presentation about how simplicity enables an evolutionary software architecture.
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents Let’s look back at the workflow Max and his team used to build a solution to their problem. First, they invested in problem understanding so that they then could decompose the problem into almost independent subproblems. Finding solutions to the subproblems and composing these together into a solution for the whole problem were the next iterative steps. Once a consistent...
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents Max and his team can now build software in steps, adapt to new business needs and technology changes, and evolve the software architecture accordingly. But like most teams after a while, they get the feeling that they lose speed. Development takes longer, features get completed less and less. It’s time to improve the code base and invest in innovation. But unfortunately...
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents Even if you invested a lot of time upfront to get all the requirements and to make wise technology decisions, requirements and technologies will change. Requirements change because the stakeholders see new possibilities or there were misunderstandings. Technologies change all the time and at some point, you have to keep up or the product will die. How can we design a software...
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
Max wants to get feedback about the architecture and the software his team built often and as early as possible. Earlier feedback means that the team can correct its course earlier and thus reducing waste caused by building the wrong stuff.
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents Max knows now how to add new features and how to extend the architecture in an iterative and incremental way. He knows how to split and defer decisions. But how can his team keep adding stuff without breaking what is already there? Breaking existing stuff is very time consuming and frustrating. Re-work is what costs teams a lot of their capacity. Instead of building new...
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
Max has the challenge that there are a lot of architectural decisions that have to be made. But how can his team make good decisions with only limited knowledge because they build the software incrementally and need decisions early to start developing?
These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
When we build software with an agile approach, we build features incrementally and iteratively.Incremental = one feature after the other.Iterative = we build the first version of a feature, get feedback and improve it in the next iteration.