Last week I attended Dan North’s workshop “Testing Faster”. Dan North is the originator of the term Behavior Driven Development (BDD). The whole workshop was amazing but there was one thing which really surprised me. Since BDD is basically another way of Test Driven Development (TDD), I would have expected that having a high test coverage was one of Dan’s goals when writing software. But what I learned was that he actually doesn’t care about the overall test coverage. He explained that in a very convincing way. In this article I wrote down what I learned about the test coverage.
Since I attended a Management 3.0 workshop a couple of weeks ago there is one thing that I cannot get out of my mind. It was a simple metaphor: A good manager is like a gardener. Imagine a garden full of vegetables, fruits and other plants. The gardener’s job is to create as much value as possible out of the garden. Value might be the fruits that the plants create. The more tomatoes, strawberries and potatoes grow the more value comes out of the garden.
I wanted to write about that topic for weeks or maybe even months. But I never started. Until now! Something was holding me back from writing this article. It was almost like a fear. Maybe the fear of not being good enough. I was not sure what exactly to write down and how to write it. I didn’t even come up with a good title for that article and without a great title I didn’t want to start writing at all. The title has to be short and crispy. It has to catch the reader’s attention! It has to seem relevant to search engines. It has to be as perfect as the whole content of the article.
Today is a very special day for me! Exactly one year ago I published my first article on this blog! Today is the first anniversary of team-coder.com so I decided to write a short article about the things I have learned within the last year and the things I have planned for the next year.
A few months ago I published a blog post about my team’s transition from Git Flow to trunk based development. We have found a way to get our code into the master branch very quickly. At the same time we are always ready to release our master with confidence which is the basis for our continuous delivery pipeline. We have less merge conflicts and we are able to enable or disable features at any time.
One topic I didn’t cover with this previous blog post is how and when we review our code. Within the last months we have found a practice that works very well for us. In this blog post you will learn how we still use small branches and pull requests without losing the benefits of trunk based development.
I bought my first Smartphone in 2011. It was an HTC Desire with Android running on it. A few weeks earlier I had started to learn Java so since Android apps can also be developed with Java I had to create an app for that great device! Now, five years later, I’m building the same app again but with new technologies. My goal is to train my skills. In this article I want to tell you how I improve my skills as a software developer with that pet project and how you can do the same with your own little project!
I have worked with Git Flow for a few years and it helped me a lot to structure my Git branches. However, I have encountered some problems with Git Flow, most of them coming from long-living branches. The solution to solve those problems is trunk based development! It is an amazingly simple technique which is also the base for effective continuous delivery. In this article I tell you how I have made the transition from Git Flow to trunk based development with my iOS development team at HolidayCheck. You will learn what is the most important step to get there and what benefits you will get from trunk based development, so keep on reading!
Git is a great tool if you have multiple developers working on the same code base. However, there is one thing which can be very annoying if your team uses Git: Merge conflicts! Two developers have changed the same part of the code and then Git doesn’t know what to do. Fortunately, there are a few tricks to avoid merge conflicts and this article will tell you how!
Coding guidelines help software developing teams to write consistent code which is easy to read and understand for all team members. Establishing such guidelines can be problematic if it is done wrong but it will be very beneficial for the whole team if it is done the right way. In this article we tell you what is important if you want to establish coding guidelines in your team successfully.
SOLID is an acronym for five principles that help software developers design maintainable and extendable classes. It stands for Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion. The acronym was first introduced by Michael Feathers and is based on Uncle Bob’s paper Design Principles and Design Patterns.
This article is a summary of the SOLID principles as originally introduced by Uncle Bob. I explain each of the five principles with an example.
There are many ways to make decisions in a team. Most teams use always the same style to decide things. Unfortunately there is not one way which is perfect for every situation. If you choose your decision style depending on the context you will come up with much better solutions for important questions.
Mob Programming is like Pair Programming but even more amazing! Instead of two people working together you have a whole team “working at the same time, in the same space, at the same computer, on the same thing” (http://mobprogramming.org).
In this article you will learn how Mob Programming can help your team to share knowledge, improve the team spirit and, by the way, develop great software!
Coding in a team requires more than just coding skills. A modern software developer is not only a programmer but also an architect, communicator, teacher and learner. There are many tools and practices that help developers to work effectively in a team and to create code that is maintainable and extendable by all team members.
In this article you will learn what is important if you want to develop great software with a team. Great meaning the code is working, clean and easy to change.