The development of a company and its working student(s)

Hello everyone! Today I would like to give you a little insight of what it means to be a working student in a start-up.

To start, I will tell you something about myself and my early days at acrontum. Afterwards I will describe how the company has changed with the increasing number of employees and what challenges this has brought for myself and my colleagues. To conclude, I will summarize the impressions and experiences I have collected over the past 2 years.

About me

My name is Anton, I am 26 years old and have been working for acrontum for almost 2 years now. I started as working student and have been working part-time for half a year. At the same time, I began my distance study at the Wilhelm Büchner university in the direction of informatics, focusing on app development. The reason I started with acrontum was to apply my study learnings in practice.

The start of a little journey

When I started our team consisted of 2 developers, a designer, a consultant and myself – the working student. My job was to set up the IT-environment for new employees, plan a future-proof infrastructure and to manage the servers for it.  Since I already had professional training as an IT-Administrator, I knew how to tackle these tasks.

I also participated in some pretty cool development projects back then. One of them was to create a Christmas browser game together with our designer Per which was presented to our customers afterwards. Of course, this project had to be planned and organized from the beginning which gave me a good first impression of our companies’ processes.  Supported by an engine called “Construct 2” (that already provided most of the important functionalities such as object and collision handling)  we were able to develop the game within only 3 weeks. The finished game was a simple 2D-platformer in which a Santa Claus had to silence employees with gifts – a very good company policy in my eyes. Another project was to setup a vHost generator, that creates a backend environment for our devs in just one command. This allowed me to work with Laravel for the first time. In short, I had a lot of varied and challenging activities right from the start.

Changes incoming!

After my first projects slowly leveled off, the starting signal for the big change came a few months later. We managed to acquire a really huge project, which lead to more tasks, more employees and new challenges. While there were only five of us, every employee could simply send the tasks directly to me: there was no defined process. However, while the company grew, these processes became more and more necessary in order not to lose track of the tasks and to be able to manage them efficiently.

The server structures I implemented were also put to a test and had to be adjusted here and there - mainly because some things turned out to be not as optimal as planned.

Due to the fact that we were managing several parallel projects, we had difficulties in the beginning, because us developers were always jumping back and forth between them, which made it really hard to focus on a specific topic. The internal restructuring of our company into project teams helped us to solve this challenge. In this process, fixed resources (employees) were allocated to the individual projects and, if necessary, a jumper was designated to a shared resource. A clear distribution of roles means that everyone now has a contact person and challenges can be solved quickly as a team.

Working in these teams allowed me to learn a lot about the entire web development process. With this knowledge I was ready to take on more responsibility and was even allowed to develop a large part of the backend on my own for an important customer project.

Freedom to create smart processes, flat hierarchies and fantastic colleagues are the factors that make acrontum a great company.

Our steady but organic growth turned out to be a great blessing for me as I could build up my knowledge continuously. This knowledge built-up came hand in hand with increasing trust from my colleagues in my abilities, so that I developed into a respected member of my project teams. If I were faced with the choice to start my career in a start-up again, I would certainly make the same decision due to my time here.

24 Oct 2018

Insights English

by Toni

Documentation Driven Development - Part 1

At acrontum we made the decision after plenty of careful consideration to adopt a new and growing trend, “documentation driven development” via “swagger” and now the newly updated specification, “OpenAPI 3”.

Documentation driven development (DDD) is not something new (some of its earliest concepts date back to 2011), but up until recently it never had an officially accepted name, nor an industry standard for the world to agree upon. It is the process of describing & designing API's and what one expects as a request and should respond with. This enables a front-end team to easily use an API within their apps and mock the response without an actual API to talk to.

Documentation driven development at acrontum is very simple and essentially boils down to a two high level and basic principles:

  • Design the API first, then build it
    • The API design must adhere to the OpenAPI Specification (formerly known as Swagger)
    • The yaml file can be broken up with swagger-chunk
    • The finished result of the API design should be a Yaml or JSON file
    • The actual API routes should be built on what is documented in the design
    • The client, eg the browser, should communicate with the API via a generated file, built from a tool such as swagger-code-gen
  • An endpoint not documented should not exist
    • A JavaScript front-end engineer using a generated DDD API access file should not look outside of this file to access the API
    • As all routes must be documented, any other routes can be seen as not required &/or dangerous

Adhering to DDD has simultaneously increased development speed whilst solving a growing issue regarding how the front-end and back-end teams both build and communicate. Further more this is not limited to company cross-team dynamics but also expandable to cross-company communications. 

Case Study

A recent project for BMW saw acrontum developing multiple API’s adhering to the aforementioned DDD principles where the main API was consumed by an Angular5 application, also built by acrontum.

Before work commenced, the API’s were designed using the Swagger2.0 spec. Upon the agreed design, both the front-end and back-end team could commence work simultaneously. The front-end team knew how the API would look when complete and could simulate the API using a mock server outputting example content. Conversely the back-end team could pick and choose which routes they wanted to build as and when they felt it right: Not having to build the routes in an order requested by the front-end team resulted in a far quicker time to staging for real testing and higher quality code base.

Change request, as with any project, happen as the client realises new potential. As and when change requests arrive that affect the back-end, the first step was to evolve the API design, ie the DDD file. After publishing the changes to the new API design(s) both the front-end and back-end could pull the updated changes and keep on building.

In addition to this, one of the API’s we built would also be consumed by a 3rd party application and once again, as the API was clearly defined by the DDD principles the said 3rd party could happily mock the API’s responses to build their part without much if any interaction with the API build team.

Looking to the future

DDD has given us some very big gains as described, but what could the future look like and how do we aim to streamline this process yet further.

Currently the API design must be written in a single Yaml file. When the API gets bigger than trivial the need to break the file down into sizeable chunks becomes a must, this is where swagger-chunk comes in. swagger-chunk allows the developer to write many smaller and manageable Yaml files which swagger-chunk then combines together into one.

Swagger-chunk is one step in the right direction, but it can be easy to get lost in a myriad of similar looking files. Further more, designing an API does not necessarily depend on skill of a developer if there were an alternative to writing pure Yaml chunks…. Enter the open source project of openapi-gui.

Openapi-gui is a graphical user interface to building the API design. The API designer does not require anything more than a web browser and technical knowledge on what a RESTfull API should be and deliver. In laymans terms, the API design can now be realised by a skilled technical product owner.

At acrontum we have yet to trial this technique and tool in production, but this does not mean we are not designing new processes to trail this, stay tuned for a future analysis...



11 May 2018

Technology English

by John

Recap: EDCH 2018 - Editorial Design Konferenz in München

Oder: was hat Editorial Storytelling mit UI zu tun?


Zweieinhalb Tage, mehr als 70 Sprecher, vom unveröffentlichten Indie- bis zum arrivierten Zeit-Magazin, junge Illustratoren und erfahrene Magazin-Denker, gelangweilte Modefotografen, Datenjournalisten die Feuer und Flamme sind für das, was sie tun. Klassische Typografen, „Wir sind Journalisten“ und Infografiker: alle versammelt in der alten Kongresshalle in München.

Die bekannten Gesichter der Branche sind auch da. Wirklich interessant aber sind Projekte wie republik, Büros wie yaay, Magazine wie Missy, the Mold oder Weapons of Reason, Fotografen wie Claudia Kent.

Und, ja: was hat das alles mit der Entwicklung und Gestaltung von nutzerzentrierten, smarten User-Interfaces zu tun? Das: wie bei Walden muss ein bekanntes Thema neu gedacht und klassisch verpackt werden, muss die eine Idee konsequent dekliniert werden (das neue Erscheinungsbild von Isuzu) und wie bei dem von Verena Gerlach gestalteten Buch „Houses of Taswir“ braucht der Nutzer eine sehr genaue visuelle Anleitung dessen was zu lesen bzw. zu klicken ist.

„Storytelling“ ist also nicht nur ein redaktionelles Werkzeug, „Storytelling“ ist auch ein Werkzeug UIs verständlich und funktionell eindeutig aufzubauen, sie in ein Corporate Design einzubinden und so zu gestalten das der User sie gerne nutzt.

Illustration: Son Luu Vu hier und hier 


14 Mar 2018

Design Deutsch