Laravel development for companies in Mannheim

When an application stops at three in the morning in Mannheim or Ludwigshafen, nobody waits until daylight. The region is one of Germany’s densest industrial areas, with chemicals, mechanical engineering, electrical engineering, energy and logistics along the Rhine, and a large part of it works continuously.

On top of that comes an unusually high density of research and development. Considerably more people in the metropolitan region work in research-related occupations than the national average, and it shows in the enquiries: the people across the table usually know exactly what they want.

Continuous operation shifts the priorities

Technically, an application for shift work differs hardly at all from any other. What differs is how faults are weighed. A failure that would be an annoyance elsewhere holds up a shift here, and the cost of that bears no relation to the development effort somebody saved.

So in projects like these we put more weight on the unremarkable things. What does the application do when a neighbouring system does not answer? Is an aborted transaction rolled back cleanly or does it sit there half done? Can somebody work out what went wrong without us?

These questions cost little while building and decide everything in production. What that looks like in practice is described under Laravel development.

Updating without stopping

The second peculiarity concerns maintenance. Where there is no quiet moment, an update has to be possible while running. That is doable; it only demands preparation. Changes to the database come in small steps, the old and new versions run alongside each other for a while, and the interfaces have to tolerate both.

Build that in later and you pay twice. How we look after applications in service is under maintenance and support.

The fallback belongs in the design

An application running in shift work will at some point be unreachable. A network fault, a power cut in the wrong part of the building, a neighbouring system whose maintenance takes longer than planned.

The question is not whether that happens but what the people on the floor do then. Usually the answer is plain: they write it down and enter it later. For that to work, the application has to allow later entry and keep it recognisable that a value was entered after the fact. Something like this is rarely retrofitted, because in that moment other things are pressing.

Who gets called during an incident

In an environment that works continuously, responsibility during an incident is not a formality. Between plant control, network, database and application there are often four responsible parties, and in case of doubt each points at the next.

So we settle beforehand how to tell that the problem is at our end and how to tell that it is not. Part of that is our application writing something usable into its log when something fails rather than merely stopping. That costs almost nothing while building and decides, at three in the morning, whether somebody gets further in ten minutes or in two hours. How we word agreements like these is under maintenance and support.