Estimating a story in hours is common practice. But often, estimations in hours prove not to be accurate. How much time it takes to complete a task depends on a lot of variables. There’s a better way. Estimating stories by size rather than the time needed to complete it, results in more reliable planning, and allows the team to respond when their pace slows down.
It’s easy to estimate the number of hours it takes to complete a task. Everybody can do it. It might even be the easiest way to estimate. So, if that’s not the way to go…
Over the years, building and testing software that runs on physical servers has become the status quo. The database is the most important part of the application. Usually, it’s the only dependency an application has. Testing has become a no-brainer. Most of the tests are unit-tests and we run end-2-end tests manually or with Selenium to see if everything integrates properly.
Moving an application to the cloud is usually not too difficult. It will require some minor modifications. So why change anything to the way we build software?
1.) The difference between on-prem and cloud
In the end, every application runs on a computer. The cloud, and…
Applications automate processes. Somebody explains the process and someone else builds the application. Seems straight forward, right? Or is it? Perhaps this video changes your mind:
Describing a task as simple as making a sandwich seems simple, but as you can see, plenty of things that can go wrong. Ironically, many software development projects have a lot in common with this video.
It’s impossible to describe a process perfectly. As you can see, assumptions can have a big impact on the final product. It’s not just the person who writes the instructions who’s making the assumptions, the person who’s…
Canary-releasing or zero-downtime/blue-green deployments are made easy by the tools and techniques we have today. Running a second instance of a service is a piece of cake. Especially in the cloud. But aren’t we forgetting something?
Canary-releasing and blue-green deployments have something in common: They require two versions of the software to be up and running at the same time.
It’s not just a matter of running multiple instances of software somewhere. You’ve got to think about backward compatibility, too! One of the instances will break if it’s dependency isn’t compatible.
What’s the most common shared dependency? The database! Blue-green…
Domain-Driven Design, that’s what you use when you’re building Microservices. It’s a technique that can be used to cut monoliths into small bits, and it’s about Aggregates and Event-Sourcing. Or is it?
The book Domain-Driven Design by Eric Evans first appeared in 2004. It’s a book about communication, language, context, and models. And it’s a book about object-oriented programming and design patterns.
In essence, Domain-Driven Design is about creating a solution that reflects the problem at hand. It’s about designing software together. Not just the development team, but both the development-team and domain-experts.
Domain-Driven Design is about shared understanding.
The ubiquitous language
Assumptions…
Installing software automatically is a piece of cake. Everybody can build a Docker container. Creating a deployment-pipeline is easier than ever before. But every system is different, and not every system can be updated without causing downtime.
Mistakes are easily made, and IT-systems are fragile. Some systems are too big to be deployed automatically. Some teams depend on other teams and as a result, systems depend on each other. Implementing CI/CD is easier said than done. It’s not just a matter of building a deployment pipeline. It impacts (almost) every team and system in the organization. …
“Pipelines”, that’s what the menu in Azure DevOps says. Nothing more, nothing less. They can be used for anything. They’re a great tool to deploy software to resources in the cloud. But a pipeline can do much more than that.
Companies race each other. Who ships something new to the internet first? Who can serve a new market first? Deploying quickly, and often, is a huge competitive advantage. To be able to bring something new to production, the game is to get the software to the end-user as quickly as possible. Preferably before the feature is completed. That way, we…
Everybody uses integers, doubles, strings, and DateTimes. So, they’re a part of the dotnet framework. But every project has project-specific data-types too.
Imagine writing software for a powerplant. The calculations are in KwH, MWh, and GWh. And they are often represented as integers or doubles in the code. It would make more sense to have a KWh data-type instead. So why not create a custom data-type yourself?
How to create a value object
Technically speaking, creating a new data-type is just a matter of creating a new struct or class. To get it to behave like any other data-type, implement the == operator and the !=…
An application that has a dependency on a SQL database needs to connect to an instance of a database that has a compatible schema. Otherwise, the application breaks. Changing the database means lots of work. Not to mention the risk associated with changing the schema itself. Plenty of reason not to release your software too often. Or is it?
When you do something often, you automate it. If you are releasing your software often, updating its database schema is a great candidate for automation. It is easily automated, too. Especially with Entity Framework and a code-first approach.
What’s code-first?
Traditionally, a DBA…
Manual testing and manual deployments are a thing of the past. Especially with modern architectural patterns like event-driven architecture. Microservices architecture tends to result in complex IT-landscapes that host different versions of all sorts of applications, all the time. Many microservices have dependencies on cloud services, too. So how can you build and test a microservice in a cheap, fast way and be sure everything works?
Automated testing seems an obvious solution. …
