Trunk Based Development is a way of working with a collection of techniques and processes aimed at organizations that want to speed up their software delivery cadence. This goes a bit beyond simple branching strategy, as we lean on some tools to help us reach its full potential.

If your team wants to reduce merge friction, have the full picture about each other work, and release faster, then keep reading!

Why consider Trunk Based Development?

This experience is based entirely on our own, a 3-person development team. We are an experienced team and that makes Trunk Based Development a bit easier to implement.

We currently carry our work using feature branches, that are long-lived in our case. This makes it a problem when we want to have a release from our master branch because the probability of having conflicts increases. In our case, having many feature branches combined all together and then splitting this work apart in order to generate a release branch was creating some friction that we wanted to fix.

We want to be able to deliver our work to the production environment in a more streamlined way, and that is why we decided to give Trunk Based Development a go.

We will focus this article following the needs of our team like we said earlier. We have some good CI/CD practices in place already, but Trunk Based Development will enable us to achieve a truly continuous deployment layout, making the release process more streamlined.

It is a new workflow for us, different from the traditional feature-branch system, and it requires careful planning to implement correctly. The good news is that this planning is really easy and adapts perfectly well to any kind of team, no matter how big.

Trunk Based Development vs. GitFlow

There are other branching strategies out there with their own pros and cons. One has to consider what is best for the team and what is possible to achieve with the current resources. In our case, as we mentioned already, we are a small team with an easy flow of communication.

I personally recommend this article to a full in-depth overview of both pros and cons.

Prerequisites

Being successful at implementing Trunk Based Development on a team is a task that requires attention to detail and a methodical approach in order to achieve its maximum potential. Let’s get an overview of some prerequisites that are necessary to be successful when implementing a TBD workflow.

Small batches

Developers usually push their code to the main repository once the task is finished, or maybe once a day. They do this by using short-lived local branches from the trunk. When implementing TBD the development team is encouraged to push small batches of their own work as often as possible, to avoid any kind of merge problem.

MVP mindset

The most important part about the success of Trunk Based Development is the team’s mindset. There has to be a change in mindset towards an MVP (minimum viable product) workflow, to fail earlier and safely. Features should be built in iterations, bugs should be fixed ASAP.

Feature flags

Feature flags are one of the key technical tools that usually go hand-in-hand with Trunk Based Development. This helper system allows for the integration of flaky or otherwise potentially risky code under a condition that can be easily toggled.

An easy and flexible package for feature flagging is: https://github.com/bestit/flagception-bundle

This PHP package already contains all the necessary workflow operations for flag toggling and setting.

Technical approach and advice

General conventions

• Despite Trunk Based Development encourages to work directly in a trunk (production branch) and push changes there, we need to facilitate the process of code review via pull requests, so we advise you to keep working with feature branches.
• Always create a feature branch from trunk — the branch that we are deploying on production environment. In legacy repositories usually named as master, or in new ones main, you could create yours — trunk.
• Before pushing of feature branch to origin, always rebase on top of the trunk.
• Merging of feature branch PR to the trunk should be done using squash strategy to keep the history linear and straightforward.

Workflow conventions

• Divide local work into small batches
• Push feature branches to origin asap and create a pull request, so it could be reviewed and merged into trunk earlier minimizing potential conflicts, as the changes are small.
• Flaky/untested code should be wrapped in a feature flag
• Ramp up the test suite
• Release from trunk using tags

Implementation

Shifting work from GitFlow and variants to Trunk Based Development can seem like a daunting task, but it is mostly a mindset change. Your team will soon benefit from an improved release cycle, doing much less manual work, and having powerful tests to back the releases.

Proposed general steps for the implementation:

• We need to create a trunk branch from master and make it protected. We will keep development branch in parallel to be able to switch to the legacy process easily. Developers are encouraged to use trunk and create any feature branches, push small batches, and code review as early as possible.
• Focus on having unit tests covering new functionality. Manual QA should be a process that should go much faster now.
• Implement a feature flag solution. This can be either a Symfony bundle or just some configuration files and if() conditions. Wrap flaky or untested code that is already present in the trunk, so it can be released without any major modification. See https://github.com/bestit/flagception-bundle
• Verify that the flag solution configuration is good for your setup and your team.
• When planning release, create tags from trunk for QA approval.

Step by step guide for developers:

• Always keep local trunk up to date.
• Suppose we have a task called feature-101, create a local branch task/feature-101 for it.
• Implement work.
• Send the branch for review in a PR as soon as a small piece of functionality is ready. Cover missing work with a feature flag. This flag is open for test and closed for production environments.
• Merge into the trunk. Allow the code on test to be tested with the flag open.
• Remember to update your local trunk often as code is sent there frequently.

Step-by-step orientation guide for QA

• Test work should be done with the flag open. Access the configuration in the profiler to verify.
• In case it is closed for the test environment check with the developer how to proceed.

Trade-offs

As with any methodology, Trunk Based Development is not a perfect solution, there are a few trade-offs to consider.

• Keeping all developers in sync is important, and failing to do so can lead to unexpected merge conflicts.
• There is a heavy reliance on unit tests and QA approval.
• This system relies on the effectiveness of the automated CI/CD tools, so keeping them up to date is very important.

Useful links

• Trunk based development methodology — https://trunkbaseddevelopment.com
• TBD vs GitFlow — https://www.toptal.com/software/trunk-based-development-git-flow
• Feature flag library for PHP — https://github.com/bestit/flagception-bundle

How to implement Trunk Based Development was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

After the great success of our first hackday at SEVEN SENDERS, we decided to conduct a second hackday in 2019.

This time, 40 hackers mainly from product & engineering collaborated for one day away from work.

The goal was again to explore interesting ideas that might be beneficial for us in form of a software prototype and demo them at the end of the day.

See our video here to get some great impressions from the day.

Again, our hacks ranged from feature prototypes to application of current technologies to internal tools for our teams.

It was great to see the quality and impact of the hacks improving quite a lot since half a year ago.

Our winning hack was put into production shortly afterwards and is now used by several team members to help them in tedious data analytics tasks.

Due to the great success, we have now planned to continue and further evolve our hackday setup in 2020.

Want to be part of the our next hackday ?

Join us — we are always looking for great talent !

Hackday #2 at SEVEN SENDERS was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We cannot negate that we’ve found ourselves attending one meeting that felt like we were wasting our time with a “monologue” that is either hard to follow or doesn’t seem so interesting as it could.

Therefore, I was thinking about it and I tried to get some keys to improving their general quality. It applies to all presentations but also tech-talks and other tech presentations in which engineers are usually involved.

Structure of the talk

To explain how I think a good presentation should look like I will address three main topics that are relevant to structure and design your presentation.

1. Content of the presentation: what message do you want to convey to whom and how?
2. Design and Layout: how you can design an easy-to-follow presentation that supports your talk instead of taking away the attention from what you are actually trying to say.
3. Lastly, I think also the audience is responsible for making a tech talk successful, so I will also add a reminder about the role and responsibilities of the listeners.

Consider your audience

When you prepare your presentation, ask yourself:

• Who is attending the talk?
• Which backgrounds do they have?
• Which position do they have?
• Which information is relevant to them?
• Do they have to know all the keywords that you would like to use?

Introduce the topic

Create some atmosphere. Try to answer these questions:

• Why should they listen to you?
• Why should they spend their time in another meeting?
• What will they have learned by the end of the talk?
• What is your main message?

Every meeting should have an output and an outcome. Keep it in mind.

Create a Storyline

• When preparing the main content of your talk, think about a storyline that connects your arguments. This makes it easier for the audience to follow.
• Stick to the messages that are necessary to explain your idea or concept.
• Leave out any unnecessary information that is not relevant to the core of your message.

Build a conclusion

Summarize the main conclusion(s) in a concise way:

• What is the conclusion of this meeting?
• What are the learnings from this meeting?
• What are the open questions or next steps?

Design and Layout

Write less, talk more

• A tech-talk is about learning new ideas and concepts.
• A presentation should support your talk, not replace or replicate what you have said.
• The more words on the slide, the fewer they will be remembered.
• Use visuals/graphics that support your talk instead of additional text.

Large fonts

If you have some code to present, consider:

• If it is a picture: use large fonts inside.
  I recommend using https://carbon.now.sh/ for simple snippets.
  Or just screenshots from your favorite IDE.
• If you will code in live: prepare your editor in advance.
  Use the Presentation Mode of your IDE.

Role of the Audience

Responsibilities of the attendee

• No unnecessary phone usage, like Twitter, Instagram, Facebook, WhatsApp, Telegram, etc.
• Keep your questions for the questions time, unless the presenter mentions at the very beginning that you can ask at any moment. Usually, it’s better not to interrupt the topic, so we can ask the questions at the end.
• Show interest in the topic. The presenter should have spent some time preparing the slides for you.
• Pair with the presenter the interest of the topic. This is also the responsibility of the presenter. You both should be eager to learn more about the topic.

Inner questions

• Was it worth the time that we all spent in this room?
• Do we regret the attendance of this meeting?

At the end of the meeting, we should ask these questions in order to improve. Ask other people for their feedback, so we can grow further and together.

How to improve your tech-talk (or any other presentation) was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Tool: SonarCloud

SonarCloud is the hosted version of the Sonar tools suite, including SonarQube (self-hosted) and SonarScanner (different scanner agents e.g. generic, maven, gradle…). SonarCloud allows you to analyze your code through an appropriate SonarScan agent and easily record the results in a centralized location. Your team can then access a quick and simple interface to evaluate their code and take informed decisions on how to proceed. Isn’t that exciting?

SonarCloud revolves around projects: these are essentially units of code that are built from a single code base. The code of each project gets parsed through an appropriate agent to identify issues; the results are then sent to SonarCloud to be grouped by branch. The general expectation is that short-lived branches will be merged into a specific long-lived branch; this allows the interface to assess a branch impact on the existing code and helps you decide whether a feature branch is mature enough to be merged.

The distinction between long- and short-lived branches is also helpful in reducing noise: code quality graphs take only the former into consideration, visualizing improvements only where it matters. These can be customized to select specific measures and with the version naming of your choice.

Surely you have spent many hours writing appropriate tests for your code. SonarCloud can parse the test reports providing a good estimate on your code coverage. Depending on the different agents, the tests are either run automatically or you will have to provide the test output in an appropriate format.

The Idea: Code Quality

All of this is well and nice, but there is an unavoidable question: what is code quality? It is surely a matter of perspective and different use cases, how is it possible to have a one-size-fits-all solution?

SonarCloud provides two levels of abstraction to make it easier for you to customize its rules to your needs. Quality profiles are closest to the code: they group sets of rules to trigger certain warnings or evaluations; quality gates, instead, are more abstract: they group rules evaluating the number and severity of warnings, to return a uniform evaluation of code quality. In other words: quality profiles define what a violation is, quality gates define how many violations are considered acceptable. While quality profiles are necessarily language-specific, quality gates depend only on the results of quality profiles, and can be used as a common frame of reference to evaluate projects in different languages.

Still, does it really work? Can a set of rules replace careful review and mindful analysis? That is obviously not the point: the tool works very well out of the box to highlight possible issues. The maintainers of the project then need to go through the flagged items and assess the actual severity of the issue. After that, SonarCloud allows the user to modify the initial evaluation (change the severity, mark it as not an issue, or an issue of a different kind, open a ticket…); such a change will be saved and tracked, so the issue will not resurface when the same code gets propagated across branches.

Overall, code quality is graded according to five core parameters:

1. Bugs: issues that can make your code unreliable
2. Vulnerabilities: issues that can put your code at risk of attack
3. Code smells: issues that make your code harder to read
4. Coverage: how much of your code is covered by tests
5. Duplications: how many times a bit of code is repeated across the code base

Depending on your needs, you might want to weight some of them more than others.

The Implementation: Pipeline integration

To have proper results, the code scan needs to be run quite often. While integrating it into the pipeline seems like a great idea, it may come at the expenses of pipeline runtime. We found that running a scan for every commit in every branch was a little too much for us, so we opted for a model where the scans are run in two cases:

1. for each branch that has an open pull request, because the result of the scan will be necessary to evaluate the final impact on the code base; and
2. for each commit in the master branch, because their count should be limited to branch merges and the results are important for historical evaluation

Integrating the SonarScan generic agent into our Bitbucket pipelines was quite easy, as we simply needed to provide an additional step to be run from an custom docker image containing only the agent itself. This way we managed to support most of our projects without having to modify our CI images. Even where the generic agent was not supported (gradle) and we had to made a couple more changes to our build process, the installation was not particularly challenging. In this case the installation and configuration of the scanner was managed through the step definitions of the build tool itself.

The biggest challenge we faced was integration with monorepos. The entire environment seems to be built around the paradigm “one repository, one project”; if your team is using one, some integrations will not be available (e.g. the Bitbucket widget) and some additional scripting will be necessary if you do not want to scan each project every time a scan is triggered.

The evaluation

Despite some minor downsides, our overall impression is that SonarCloud does provide useful insights on how well your team is progressing towards a more secure, more maintainable code base and, as such, is a very valuable addition to a developer’s toolbox.

Improving Code Quality with SonarCloud was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Content

PHP 7.4

• Typed properties
• Arrow functions
• Limited return type covariance and argument type contravariance
• The null coalescing assignment operator (??=)
• Unpacking inside arrays
• Numeric literal separator
• Weak references
• Allow exceptions from __toString()
• Multibyte String
• OPcache
• strip_tags() with array of tag names
• Custom object serialization

PHP 7.3

• FastCGI Process Manager
• Multibyte String Functions

PHP 7.2

• New object type
• Abstract method overriding
• Parameter type widening
• Allow a trailing comma for grouped namespaces

PHP 7.1

• Nullable types
• Void functions
• Symmetric array destructuring
• Class constant visibility
• iterable pseudo-type
• Multi catch exception handling
• Support for keys in list()
• Support for negative string offsets

PHP 7.0

• Added strict_type directive
• Scalar type declarations
• Return type declarations
• Null coalescing operator (??)
• Spaceship operator (<=>)
• Constant arrays using define()
• Anonymous classes
• Unicode codepoint escape syntax
• Closure::call()
• Group use declarations
• Generator Return Expressions
• Generator delegation

PHP 7.4 most interesting features

From 28 November 2019! PHP 7.4 Preparation Tasks.

Typed properties

Class properties now support type declarations.

Arrow functions

Arrow functions provide a shorthand syntax for defining functions with implicit by-value scope binding.

Limited return type covariance and argument type contravariance

The null coalescing assignment operator (??=)

Unpacking inside arrays

Numeric literal separator

Numeric literals can contain underscores between digits.

Weak references

Weak references allow the programmer to retain a reference to an object that does not prevent the object from being destroyed.

Allow exceptions from __toString()

Throwing exceptions from `__toString()` is now permitted. Previously this resulted in a fatal error.

Multibyte String

Added the `mb_str_split()` function, which provides the same functionality as `str_split()`, but operating on code points rather than bytes.

OPcache

Support for preloading code has been added.

strip_tags() with array of tag names

`strip_tags()` now also accepts an array of allowed tags:

Custom object serialization

A new mechanism for custom object serialization has been added, which uses two new magic methods: __serialize and __unserialize.

The new serialization mechanism supersedes the Serializable interface, which will be deprecated in the future.

Array merge functions without arguments

array_merge() and array_merge_recursive() may now be called without any arguments, in which case they will return an empty array. This is useful in conjunction with the spread operator, e.g. array_merge(…$arrays).

PHP 7.3 most interesting features

PHP Core

• Array Destructuring supports Reference Assignments:

[&$a, [$b, &$c]] = $d;

• `instanceof` Operator accepts Literals.
• CompileError Exception instead of some Compilation Errors.
• Trailing Commas are allowed in Calls.

FastCGI Process Manager

New options have been added to customize the FPM logging: log_limit, log_buffering, and decorate_workers_output.

Multibyte String Functions

• Full Case-Mapping and Case-Folding Support.

• Unicode 11 Support.
• Long String Support: now correctly support strings larger than 2GB.
• Performance Improvements.
• Named Captures Support: the mb_ereg_* functions now support named captures.

PHP 7.2 new features

New object type

A new type, object, has been introduced that can be used for (contravariant) parameter typing and (covariant) return typing of any objects.

Abstract method overriding

Abstract methods can now be overridden when an abstract class extends another abstract class.

Parameter type widening

Parameter types from overridden methods and from interface implementations may now be omitted.

Allow a trailing comma for grouped namespaces

A trailing comma can now be added to the group-use syntax introduced in PHP 7.0.

PHP 7.1 new features

Nullable types

Type declarations for parameters and return values can now be marked as nullable by prefixing the type name with a question mark.

Void functions

A void return type has been introduced. Functions declared with void as their return type must either omit their return statement altogether or use an empty return statement. NULL is not a valid return value for a void function.

Symmetric array destructuring

The shorthand array syntax ([]) may now be used to destructure arrays for assignments (including within `foreach`) as an alternative to the existing list() syntax, which is still supported.

Class constant visibility

Support for specifying the visibility of class constants has been added.

iterable pseudo-type

A new pseudo-type (similar to callable) called iterable has been introduced. It may be used in parameter and return types, where it accepts either arrays or objects that implement the Traversable interface.

Multi catch exception handling

Multiple exceptions per catch block may now be specified using the pipe character (|).

Support for keys in list()

You can now specify keys in list(), or its new shorthand [] syntax. This enables destructuring of arrays with non-integer or non-sequential keys.

Support for negative string offsets

Support for negative string offsets has been added to the string manipulation functions accepting offsets, as well as to string indexing with [] or {}. In such cases, a negative offset is interpreted as being an offset from the end of the string.

PHP 7.0 new features

Added strict_type directive

By default, PHP will coerce the values of the wrong type into the expected scalar type if possible. For example, a function that is given an integer for a parameter that expects a string will get a variable of type string.

It is possible to enable strict mode on a per-file basis. In strict mode, only a variable of the exact type of the type declaration will be accepted, or a TypeError will be thrown.

Scalar type declarations

From now on we can enforce the parameter types in a function: string, int, float, and bool. From PHP 5 we could already use augment other types as class names, interfaces, array and callable.

Return type declarations

Similarly to argument type declarations, return type declarations specify the type of value that will be returned from a function. The same types are available for return type declarations as are available for argument type declarations.

Null coalescing operator (??)

The null coalescing operator (??) has been added as syntactic sugar for the common case of needing to use a ternary in conjunction with `isset()`. It returns its first operand if it exists and is not NULL; otherwise, it returns its second operand.

Spaceship operator (<=>)

The spaceship operator is used for comparing two expressions. It returns -1, 0 or 1 when $a is respectively less than, equal to, or greater than $b.

Constant arrays using define()

Array constants can now be defined with define(). In PHP 5.6, they could only be defined with const.

Anonymous classes

Support for anonymous classes has been added via the new class.

Unicode codepoint escape syntax

This takes a Unicode codepoint in hexadecimal form and outputs that codepoint in UTF-8 to a double-quoted string or a heredoc.

Closure::call()

Closure::call() is a more performant, shorthand way of temporarily binding an object scope to a closure and invoking it.

Group use declarations

Classes, functions, and constants being imported from the same namespace can now be grouped together in a single-use statement.

Generator Return Expressions

It enables a return statement to be used within a generator to enable a final expression to be returned.

Generator delegation

Generators can now delegate to another generator, Traversable object or array automatically, without needing to write boilerplate in the outermost generator by using the yield from construct.

PHP development rocks. I really like to see how the language is evolving providing a lot of flexibility in order to create a more robust language like the others in the market.

Not just these nice features but also its increasing performance and speed. Especially now with the Opcache inbuild coming in this PHP 7.4.

Really looking forward to seeing the next PHP 8.

Modern PHP: know the best PHP features up to PHP 7.4 was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

As I have finally returned home after a 6 months internship in France, I think this is a good time to reflect on my experiences at the new Seven Senders office in Paris.

Let me share with you this short story about a boy from Berlin exploring the beautiful city of Paris.

Who is this guy?

Great question! My name is Jan and when I don’t watch movies I study International Computer & Media Science at HTW Berlin (sometimes…).

I’ve also been working at Seven Senders since August 2018 so I think it’s fair to say I’m one of the cool kids now. I joined 7S as a working student in Product & Engineering mostly supporting the QA and Product team with various tasks but more than anything, learning from all the experienced and creative minds in the office.

Why did this guy leave?

As part of my university program all students in my major had to do a mandatory internship in a country other than Germany. Thinking about the endless possibilities I naturally consulted with my colleagues and was lucky enough to be offered a position at the new Seven Senders Paris office which just opened up in the beginning of 2019 under the supervision of our head of New Markets Thomas Garnesson. So I packed my stuff, got myself a tiny apartment (actually it was not that easy) in Paris and flew there to start my new adventure.

The office is located in the 8th arrondissement of Paris that’s right in the city center adjacent to the famous Champs Elysées. During my time there I got to meet many new and interesting personalities (as Thomas was hiring to build a new team) and also worked on some very interesting projects in collaboration with the QA and Product teams in Berlin.

How is Paris?

Let’s keep this short! Paris is beautiful. Actually just calling it beautiful is an understatement. Every street, every shop, every corner looks like it’s straight out of a movie. Being born and raised in Berlin I am naturally opposed to any other city in the world but I have to admit that the city of Paris stole my heart a little bit.

Whether it’s just walking by the Seine, exploring the nightlife of the République area, drinking some good wine in one of the countless bars and brasseries or just strolling through any of the amazing museums and exhibitions — Paris has something for almost everyone. If you can look beyond the harsh prices and the sometimes rough attitude that some Parisians have towards non-French people, Paris is definitely a must visit! Oh yeah, and most importantly: They have a Disneyland. Enough said!

Did he even learn anything?

Naturally, since this is a university internship it had to be somewhat educational. I was lucky enough to be fully integrated in my team at Seven Senders to a point where it felt like I was a full grown member of the team. Together with my awesome colleagues Haik and Surendra in Berlin I worked hard on automating testing processes in the team and also spent a significant amount of time on projects in other departments of the company like Customer Support or Product. Working in a full time job, experiencing the day to day business and actually being able to shape the outcome of projects in a meaningful way really helped me on my path as a student and now gives me the confidence to keep working and prepare myself for the projects to come.

What will he do now?

After coming back from Paris, I was offered the opportunity to come back to the Seven Senders Berlin office and join their Core Services team as a backend developer. Being with the company for over a year now, I am really glad to have the opportunity to keep developing and learning here. Paris was a hugely instructive experience for me. Getting to know a different culture and a new environment and having to adjust accordingly is something that everyone should experience first hand.

Learning to deal with change and sometimes personal hardships might be one of the most important skills one can learn in life. So follow your dreams, don’t let yourself down, dare to adventure and stay awesome!

A big thank you goes out to everyone at Seven Senders for the opportunity and all the support on my journey and to all my friends that came to visit me!

Jan

My internship as a working student in Paris was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In march, we conducted our first hackday at SEVEN SENDERS.

30 hackers from engineering, product management, product design, marketing, business intelligence collaborated in small teams for one day away from work.

The goal was to explore interesting ideas that might be beneficial for us in form of a software prototype and demo them at the end of the day.

And of course — have fun:

The hacks ranged from new feature prototypes, applications of current technologies like machine learning and chat bots to internal tools for our teams.

While some hacks have been immediately put to daily use, others have sparked new ideas and focus for exploration. Some have even found a place on the product roadmap.

Due to the great success, we are looking forward to run the next hackday later this year and will establish it as a recurring event.

Want to be part of the next hackday ?

Join us — we are always looking for great talent !

1st Hackday at SEVEN SENDERS was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this story I would like to share our approach on “speaking data” as delivery platform and how we use Snowflake as data warehouse solution together with Looker as a BI platform to achieve that.

What Makes us Speaking Data

Just claiming to speak data and emphasizing the importance of data driven decisions is -if at all- just half the battle. We as the BI team of Seven Senders strive for making the data available for everyone in the company without the need of contacting us. We serve the other departments by providing the infrastructure and knowledge for a decentralized business intelligence architecture and as a data governance instance to make sure that we all have the same understanding of the data provided.

We do so by using Looker as a BI tool on top of our Snowflake data warehouse. This setup allows us not only to model the data on the fly in an flexible ELT process but also to share the same results internally with other departments and externally with customers and partners.

A Data Warehouse as Enabler for Speaking Data

The core of our business model is to connect merchants with prime last mile carriers worldwide. In terms of data this means many different data sources, different types of data and different aggregations. Now imagine to have all those data of different types in various unconnected data silos rotting over time without adding any value to the whole supply chain. This would definitely not be a good starting point for speaking data and for making data driven decisions.

That is why we decided to implement a data warehouse. By bringing together all the data in one central place we had the data where we needed it to be in order to generate holistic data insights.

Why Snowflake as Data Warehouse

Our decision on using Snowflake end of 2017 was mainly due to the following three factors:

1. Performance
   As stated above we use Looker and thus also our data warehouse both internally and externally. For us it was very important to not make an any compromises in terms on performance towards our customers despite using an ELT approach. Snowflake and its adaptive architecture enable very fast query times needed in such a setup.
2. Flexible Scale
   Different consumers of data have different needs in terms of computing and storage. With Snowflake we are able to adapt the power of our data warehouse depending on the user by using multiple virtual data warehouses with a different scale depending on the user. Aligning the different demands for compute and storage to different supplies of compute and storage also helps to generate saving potential.
3. Usability
   Snowflake is a ready-to-use data warehouse allowing us as a BI team to instantly scale, create, modify warehouses in a user friendly web interface. There is no need for a DevOps even if you are completely without IT background (like myself). Simply login, select the desired warehouse and adjust the computing power by means of a click.

I will share some more detailed insights on our decision for Looker as BI platform on top of Snowflake in an upcoming post.

The Result

By implementing our tool stack with Snowflake and Looker we were instantly able to generate much more value out of our data silos. By bringing the different sources together in one place we expanded our data insights to make data driven decisions. From monthly reporting to daily cost controlling and monthly performance audits. What has not been done before or just irregular in extensive excel work is now possible with a click.

In addition we were able to decrease the time to market for new data insights for our customers in our Sendwise Delivery Software. With our ELT approach enabled by Snowflake we can model and share new data insights in hours to days rather than weeks to months. This of course also helps to widely expand our customer base and with the new setup we do not have to worry about scalability or performance issues.

Take a look at the following video by Snowflake where I summarized our journey (German only, sorry).

Speaking Data with Snowflake and Looker was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The development teams at Seven Senders use state machines all the time in their projects. But when the Front End team started using State Machine inside the UI of our new application Sendwise, something clicked…

We started to have the following conversation:

PM 1: If you think about it, isn’t an application just a succession of states?

PM 2: Hum… Yes, you can see it like that for basics pages indeed like login, signup, on boarding etc… but for some other pages that we have it is way more complex!

PM 1: Let’s try to describe our product as a State Machine just to see if it hold!

PM 2: OK, but I can assure you it is going to be messy…

Indeed it is and the chart that you see on the left is still a work in progress, not all the pages and interactions have been represented!

We used statecharts website to learn the concepts about Statecharts and State Machine.

The chart on the left was made via the super tool called Sketch.systems

We use it to represent all the states of our product, all new features ideas or improvements.

It really helps us PMs to manage the complexity of the UI System.

What we learned

• Our product is way more complex than we imagined
• Some states do not have a specific UI linked to it (mostly all asynchronous state when we save content)
• Statecharts are super easy to understand for PM and it really helps to translate business idea/requirements into functional specifications

How PMs use Statecharts at Seven Senders

Imagine the following situation:

A stakeholder/customer/anyone brings a new idea/feature/improvement for your application/website/software. As PM, we look into our Statechart where this change will have an impact inside our system.
This helps us to quickly understand how much we will need to change the UI to implement this change.

With this knowledge we can better prioritise between different request when we need to develop them.

When the implementation/design of the idea/feature/improvement starts, the UI/UX designer can see quickly which states need to be designed or improved.

When the Front End team starts the work they already have their State Machine updated and all the screens/mocks for all the states.

This has helped us to drastically reduce development time for complex UI interactions.

Statecharts in product development ? was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Startup life, the next chapter — SEVEN SENDERS

Beginning of this year, I started my second chapter of startup life in Berlin.

What did I do before ?

The previous four years have been awesome.

As part of the executive team at Babbel, I helped scale the company to one of the most successful tech companies in Europe, growing to millions of paying subscribers and scaling up the from 100 to almost 500 in Berlin and New York.

It was a great journey, but somehow the most enjoying moments I had in the earlier days of scaling the company.

So — what next ?

For almost 20 years, I worked hard with 2 months off being the maximum that allowed myself a few times (and often a lot less).

I always dreamed of doing a longer sabbatical — which I now made reality: 6 months.

Why SEVEN SENDERS ?

I decided to join SEVEN SENDERS since it ticked all my boxes on what I was looking for in my next professional challenge:

• CTO position in a promising startup/scaleup
• possibility to shape product, tech as well as the company itself
• an industry i like and interesting product & tech challenges
• current size between 50–100 people overall
• a good existing tech team >15 (I am not a coding CTO anymore)
• significant business growth potential
• solid financials and business model
• enough runway (preferably recently closed Series A or similar)
• strong no BS founder team (not just a bunch of kids with money playing)
• experienced management team (or planning to hire)
• good sense of humour and fun at work
• nice office in Berlin

How did it turn out ?

After 6 months, I can honestly say it has been an excellent decision.

We are ramping up business, product, tech, team and the overall company — while building a great culture and enjoying an awesome environment in the heart of Berlin (see here for nice views of the area where our office is located).

We are building a diverse team with people from all over the world that are excited about building the leading delivery platform.

As Berlin is Europes #1 tech destination, it is easy to convince promising candidates to relocate. Especially since cost of living is still quite low compared to other major tech destinations).

​As my journey continues, I will launch further posts…

Interested to join us ? Check out our team and open positions.

Startup Stories #2 - Seven Senders was originally published in SEVEN SENDERS Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.