Map Data IV: Tracking Changes

In this article, I want to argue that the unique properties of map data make it a particularly interesting target for techniques such as change data capture in which not only the data itself but also the changes to the data become a first-class citizen. This article is part of a series about the specific... Continue Reading →

Map Data III: Editing and Processing

Like with any kind of data, to fully understand the map data design space, we need to understand both the way it is used from a consumer perspective and the way that it is produced. Understanding the different requirements of producers and consumers leads to a better understanding of the solution space and the design... Continue Reading →

Map Data I: It’s All About Relations

Map data is an interesting beast. Having worked on it for the last couple of years, I can note that many of the general data processing challenges arise. However, map data also comes with a number of particular features that set it apart. I have split this series into five parts: It's All About Relations.The... Continue Reading →

Much of Your Work Will Go To Waste

It may sound like an overly pessimistic assessment of the state of our industry. My intention is not to sound cynical, however, I think we need to be honest with young engineers entering the field of software development: There is a real possibility, that a lot of the code that you will write during your... Continue Reading →

The Trouble With Rewrites

I have a bit of a soft spot for legacy systems. They have a certain charming ugliness to them. Clearly, there is a ton of challenges with legacy projects, partly related to organizational incentives, and partly related to technical concerns. Sometimes the response to these challenges is: Let’s rewrite all of it. I think that... Continue Reading →

On Referring to your Colleagues as Customers

I have observed a pattern that companies large enough to develop internal tooling institutionalize a vocabulary that evokes the impression of a supplier-customer relationship between the teams building these internal tools and the teams using them. I would argue that saying “the customers request a feature” when talking about internal users does more harm than... Continue Reading →

On Ambitious Goals

I am a fan of setting stretch goals that are just a little bit beyond what seems realistically achievable. They are motivating and communicate a certain optimism about the capabilities of the team. However, not all dimensions of a project lend themselves to ambitious goal-setting. We should be particularly careful about goals that affect technical... Continue Reading →

On U-Boot Projects

Projects that are executed against the will and without the knowledge of the management are a particularly fascinating artifact of the software engineering world. The English term I heard used for these is “Skunkworks”. However, I particularly like the German expression for such stealth missions: U-Boot (submarine). Nobody is aware of the U-Boot until it... Continue Reading →

Architecture Annealing

The term “Software Architecture” can evoke the impression that it describes a blueprint that needs to be completed before actual development work can start. This association is natural given the origin of the term: The architecture of a building better be complete before the construction begins. Unfortunately, this vision is also at odds with what... Continue Reading →

Blog at WordPress.com.

Up ↑