by Jan Heller -

Introducing the ottonova Tech Radar

ottonova Tech RadarDaniele Franchi

We always promoted openness when it came to our tech stack. The ottonova Tech Radar is the next step in that direction.

What is the Tech Radar?

The ottonova Tech Radar is a list of technologies. It’s defined by an assessment outcome, called ring assignment and has four rings with the following definitions:

  • ADOPT – Technologies we have high confidence in to serve our purpose, also in large scale. Technologies with a usage culture in our ottonova production environment, low risk and recommended to be widely used.
  • TRIAL – Technologies that we have seen work with success in project work to solve a real problem; first serious usage experience that confirm benefits and can uncover limitations. TRIAL technologies are slightly more risky; some engineers in our organization walked this path and will share knowledge and experiences.
  • ASSESS – Technologies that are promising and have clear potential value-add for us; technologies worth to invest some research and prototyping efforts in to see if it has impact. ASSESS technologies have higher risks; they are often brand new and highly unproven in our organisation. You will find some engineers that have knowledge in the technology and promote it, you may even find teams that have started a prototyping effort.
  • HOLD – Technologies not recommended to be used for new projects. Technologies that we think are not (yet) worth to (further) invest in. HOLD technologies should not be used for new projects, but usually can be continued for existing projects.

What do we use it for?

The Tech Radar is a tool to inspire and support engineering teams at ottonova to pick the best technologies for new projects. It provides a platform to share knowledge and experience in technologies, to reflect on technology decisions and continuously evolve our technology landscape.

Based on the pioneering work of ThoughtWorks, our Tech Radar sets out the changes in technologies that are interesting in software development — changes that we think our engineering teams should pay attention to and use in their projects.

When and how is the radar updated?

In general discussions around technology and their implementation is driven everywhere across our tech departments. Once we identify that a new technology is raised, we discuss and consolidate it in our Architecture Team.

We collect these entries and once per quarter the Architecture Team rates and assigns them to the appropriate ring definition.

Disclaimer: We used Zalando’s open source code to create our Tech Radar and were heavily influenced by their implementation. Feel free to do the same to create your own version.

by Jan Heller -

4 rules for building successful cross-functional teams

Rowing boat teamJosh Calabrese
A well gelled cross-functional team acts as unit much like olympic oarsmen.

ottonova has a long history of using cross-functional teams for Software Engineering. Very early on we tried to establish them to become more productive and product centred.

It took us a few tries to get it right and oh boy, did we make a lot of mistakes along the way.

I would like to share some of our learnings and put them into basic rules that everyone can use.

Not a band-aid 🩹

Don’t put the cross-functional team structure on top of something else.

Initially we structured our engineering teams around programming languages. We had a PHP/backend team and a JavaScript/frontend team. Both teams had a Team Lead, who was also the engineer’s superior. The teams had a backlog, sprints and were working quite smoothly. Then we put cross-functional teams on top of that. It didn’t work.

Suddenly we had conflicts of interest between the cross-functional teams and the old team structure. Everyone was confused what to focus on. The Team Leads didn’t engage with their engineers on a daily basis anymore. It was messy.

Clarity for everyone should be the first priority when you want to really establish cross-functional teams. No hidden layers, no hidden agendas.

Establish team culture 🗿

A great team shares a connection.

The easiest way to create a connection is to give the team freedom to establish a unique culture and identity. Everything starts with a name.

Give your teams the freedom to chose their own name and celebrate this name with an inauguration ceremony. Everyone in the group should well understand what their purpose and vision is.

Why was the team established?

What are our short, mid and long term goals?

How will we get there?

The more independent this process is, the easier it will be for the team to form a bond and feel connected.

Empower your team 💪

A successful cross-functional team feels empowered to take care of their value stream. They have to be the clear owner of their artefacts and have all resources at hand to complete their tasks.

Take for example a team that is supposed to take care of a customer facing app connected to a backend API. To maintain the app and implement new features without dependencies the team needs a minimum setup like this:

  • Mobile engineers for the app (iOS, Android or JavaScript)
  • Backend engineers for the API (e.g. JavaScript, PHP, GoLang or Ruby on Rails)
  • QA engineers for manual and automated testing
  • UI/UX designers
  • Product Owner who takes care of stakeholder communication
  • Team or Tech Lead

Every dependency to another team causes workflow delays and disruption.

A duo at the helm 🛶

A cross-functional team benefits greatly from a strong and well gelled Team Lead-Product Owner combo.

The Product Owner handles the stakeholder communication, collects the business requirements and pours them into user stories to fill the backlog.

The Team Lead takes care of the software delivery and people management. They unblock tasks, assign experts, make sure that tickets are completed with technical requirements and resolve personal issues.

The harmony of the TL-PO pair can be make-or-break for a team and should always be considered when assembling a cross-functional team.

by Jan Heller -

Why we switched from Moment.js to Day.js

Moment.js is an awesome library when it comes to performing complex date-time manipulations. It provides a rich and clean API that covers many use cases. That aside, Moment.js shouldn’t always be the go-to library when it comes to date-time problematics. Alternatives should be considered as well.

What are the alternatives?

Actually, there are plenty of alternatives out there:

Why we picked Day.js?

This decision bases on two reasons:

  1. Lightweight – only 2.6KB gzip
  2. Similar API to Moment.js – which means easier migration

How the migration went?

All date-time functions used in our apps are located in the service date.service.ts. So the migration of this service made the switch possible for us.
In general, having the date-time manipulation centralised in one place is a good practice. It makes changes like this one possible without much effort.

The migration process

  1. Make sure that the service is 100% covered with unit tests
  2. Check if all Moment.js API usages are available in Day.js
  3. Replace Moment.js with Day.js in the package.json
  4. Adjust the service to use Day.js

Step 1. was an easy one. We just wrote the missing unit tests for our service.
In general, test coverage of utility functions should always be high.

In Step 2. we found out that the following changes were necessary:

  • Object instantiation
// Moment.js
const now = moment();
const day = moment('2019-07-12');

// Day.js
const now = dayjs();
const day = dayjs('2019-07-12');
  • Second parameter in diff is plural in Moment.js, but singular in Day.js
// Moment.js
var date1 = moment('2019-07-11');
var date2 = moment('2019-07-10');
date1.diff(date2, 'years'); // 0
date1.diff(date2, 'days'); // 1

// Day.js
const date1 = dayjs('2019-07-11');
const date2 = dayjs('2019-07-10');
date1.diff(date2, 'year'); // 0
date1.diff(date2, 'day'); // 1
  • UTC support doesn’t come out of the box with Day.js 
// Moment.js
moment('2019-07-12T15:37:01+02:00').utc().format(); //2019-07-12T13:37:01Z

// Day.js
import dayjsPluginUTC from 'dayjs-plugin-utc';

dayjs.extend(dayjsPluginUTC);
dayjs('2019-07-12T15:37:01+02:00').utc().format(); //2019-07-12T13:37:01Z
  • months() doesn’t exists in Day.js
// Moment.js
moment.months(); // ['January', 'February', ... , 'December' ]

// Day.js
dayjs.months(); // dayjs.months is not a function

The APIs are mostly compatible. Finding these key differences between the libraries helped us to tackle all the issues in Step 3 and 4.

All other changes were specifically related to our business logic.

How our bundle changed?

The migration confirmed our intentions. Our bundle is 60KB (~10%) lighter.
Gzipped size of Moment.js was 72.47KB and now of Day.js is 3.14KB (including locale and UTC plugin)

TL;DR

So far, switching to Day.js seems like a great decision. We haven’t run into any issues since our migration, one month ago.

The goal of this blog post is not to convince you that Day.js is awesome and Moment.js is terrible. But to remind you that choosing a date-time library is not an easy task.
There are many options available, so take your time and find out which one might be the best for your apps and needs.

by Jan Heller -

The QA Engineer position at ottonova

ottonova services GmbH
Some information about our QA Chapter and the QA Automation Engineer position at ottonova

We would like to use this article to give some insights on the QA Engineer position here at ottonova and to answer

This article gives some insights on the QA Engineer position here at ottonova. Since the position can be interpreted quite differently we want to answer some common questions. Here we go.

1. Is test automation part of the QA activity? If yes, what experience in which programming languages and frameworks is required here?

Yes, test automation is a very important part for us. For the automation of the web tests, we use Python and JavaScript.
The UI tests from the iOS and Android apps are implemented in Appium. Experience in using classic frameworks like Page Object Pattern and common build tools like Jenkins or GitLab CI is also a big plus.

2. Exactly what kind of tests are performed and developed (acceptance testing, regression testing, UI testing, backend API testing…)?

Regression and acceptance tests are developed and executed. The development and execution of the automated UI and backend tests is also part of our daily activities.

3. Which application are tested? The ottonova app? If so, are both versions (iOS and Android) tested?

In our QA team we test our various web applications as well as our mobile apps (iOS and Android).

4. How big is the development team and how many members does the test team consist of? How many releases would be tested per day? 

There are several engineering teams consisting of backend, frontend, mobile and QA engineers. The teams use Scrum and are organized cross-functionally. They therefore also include, for example, product owners or members of our insurance departments.

Each of our cross-functional teams has at least one dedicated QA Engineer.

6. What are the weekly working hours at ottonova? What further development opportunities do I have in your company in the area of QA?

We are flexible on all points and are happy to accommodate the wishes and ideas of applicants, both in terms of weekly hours and contract terms.

Working student contracts are limited to one year by default and have a fixed hourly wage. A permanent position after a student job (or internship) is always our highest goal.

In our employment contracts for a full-time position, there is always a probationary period of 6 months.

The development opportunities are individual depending on the employee, we support the realization of your goals where we can.

by Jan Heller -

Welcome to our ottonova.tech blog!

Hello everybody,

with this post we want to kick off the ottonova.tech blog and also explain what it’s for.

With this blog we sincerely want to give you insights on how we create the software and platform behind ottonova. The first newly founded private health insurance in a long time.

We are assembling a strong and experienced IT team and are still growing. With a focus on everything it needs to create and run a fully digital health insurance: Multi platform software engineering, cloud infrastructure, quality assurance, data science, data security, and office IT.

Our idea is to regularly publish interesting articles about our work and how we organise.

Hopefully our content is an inspiration in one or the other way to someone.

All the best and see you soon,
Jan 🚀