Interoperability between Java and Kotlin is great, but the difference in how nullability is treated can sometimes pose interesting problems. This article tackles one particular problem and introduces some Kotlin concepts in the process.

Many developers will have heard a manager ask "when is it done?" and have felt a combination of irritation and dread.

Early on in their career, most software developers develop a muscle memory for writing efficient code and avoiding code duplication. It’s unfortunate that in modular architectures, this practice can seep through into data modelling without context awareness, leading to tight coupling and constraining the software’s ability to be changed.

There are plenty of ways to build software that responds to changes in data or outside events. It can be less intuitive to come up with a solution that needs to respond to nothing happening.

DevOps is the idea, that the concerns and interests of developers and those of operations are better served when they aren’t addressed in isolation as individual silos, but in unison. As a result, the whole organization that depends on both ends up being more agile and more stable

A tool that helps with scanning for security vulnerabilities in dependencies can be a great addition to a CI/CD stack. Using it poorly can leave you with a false sense of security.

Here are my thoughts on some of the recent doubts I’ve had as someone who is usually a change agent and agile evangelist in some capacity or other.

These are questions you can ask yourself as an agile coach, as a sociotechnical delivery consultant, as an architect, as a developer, as a development manager, as an HR manager, and really as any person who plays a part in an organization’s efforts to deliver on its mission statement.

In every organization and in every team, I run into one or two customs that people tell me are part of "Scrum by the book", that aren’t actually in the book.

How do you know when having a tech lead may be taking your organisation in the wrong direction? Let’s take a look at some of the archetypical tech leads, their pitfalls and ways to go about and deal with them.

I’m a developer and I like Scrum. Not every developer does. A complaint I sometimes hear is the following:

If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration

The book The Fifth Discipline by Peter M. Senge landed on my doormat recently. I ordered it after hearing Andrew Harmel-Law of ThoughtWorks mention it at the JFokus 2020 conference (article in Dutch). His takeaway was as follows:

"Placed in the same system, people tend to produce the same results".

Once I received the book however, a line at the top of the cover caught my eye:

"In the long run, the only sustainable source of competitive edge is your organization’s ability to learn faster than its competitors"

This statement rings so many bells I’d like to dwell on just that without even going into the book itself. There are two obvious yet often missed clues here that I’d like to share.

The times I’ve worked on a project where the scope is "rebuild the existing implementation, but with new tool / techonology X", I’ve encountered various pitfalls that make these projects much harder than they need to be.

Let me offer some tips on how to deal with them.