Software Release Flow

We as product dev team are creating software artefacts and these need to be put out for usage somehow. This describes conventions and rules we use.

The bug sheriff

No piece of software is perfect, so every team that is developing software has to deal with bugs. BetterDoc is no exception.

One of our biggest advantages is that we as the product development team have a direct line to all our users. They’re sitting only a few doors away from us.

While this is enourmosly helpful in making sure we’re developing the right solution, it can also lead to situations, where we simply feel overwhelmed because everyone wants to talk to us at the same time.

To structure this incoming stream of information we have introduced a special role: The bug sheriff.

Speaking at conferences: A HowTo, part three

In part two I talked about how to turn your idea into an actual presentation.

In this final part I’ll talk about what to do when actually giving your talk.

Speaking at conferences: A HowTo, part two

In part one I talked about how to find a topic, how to find out what to include and how to prepare your talk.

Now it’s time to talk about what to do when actually giving your talk.

Speaking at conferences: A HowTo, part one

I’ve had the opportunity to talk as speaker on several development conferences during the last few years.

Interestingly, when talking about this to friends and colleagues a typical reaction when they hear about this is: “Oh, I’ve always wanted to do that as well but I’m not good enough” or similar comments.

As I had basically the same doubts just a few years ago I’d like to lay out a few thoughts about speaking on conferences and why you are good enough, no matter what you may think.

Developing a microservice in COBOL

At BetterDoc we’re currently in the process of step by step replacing an old monolithic application with a microservice landscape. Sometime in early January 2019 we talked over lunch we asked ourselves “What could be a crazy language in which we could implement one of our microservices just to prove that it can be done?”. I’m not really sure whose idea it was but one of us said “What about COBOL?”.

Of course it was meant as a joke, I mean who would start a new COBOL project in the 21st century? But I thought to myself “What the heck, why not?”. I’ve never really looked into COBOL so it sounded like a nice challenge to pick up. So I said actually tried it.

Naming things, part 3

At BetterDoc we’re currently in the process of step by step replacing an old monolithic application with a microservice landscape. While adding services whe recognized that we needed to find a consistent pattern to naming these services to keep the “service zoo” organized.

This post describes our overall scheme for naming our services.

Note that since writing this blog post our idea of how a service should be named has changed and the following rules are no longer valid. Our most recent thoughts can be found here: (Naming things, part 3B).

Naming things, part 2

I have already talked why it’s important to have a good name for your software here, today I want to dig a little deeper into naming, this time on a more technical level: Naming events.

Naming things

According to Phil Karlton there are only two hard things in computer science: Cache invalidation and naming things. We’re currently experiencing how important the latter one is. Finding the right name for something and then sticking to that name.

Joel score +1

From time to time, I check our Joel Score - partly because I see the need to improve on the topics listed there, partly because it reminds me why we do some things we do.