Inside Stories

Go behind the scenes at leading tech companies.

27 days ago

Why Enterprise Devs Are Rethinking Cross-Platform Charting

Building charts once and shipping them everywhere sounds simple - until you're maintaining separate rendering logic for web, iOS, Android, macOS, and Windows, and your "unified" solution turns out to be a web-view wrapper in a native shell.The core problems for dev teams: duplicated charting code across platforms, web-view wrappers that choke on custom interactions and synchronized multi-chart views, and libraries that fall over once you throw dense, streaming datasets at them (think financial tick data or industrial sensor feeds).The comparison is blunt about the popular options. Plotly leans hard on JavaScript, which shows up as real mobile performance bottlenecks. Highcharts is mature and accessible but web-centric at its core, so native mobile still means shipping a browser component under the hood. ECharts handles big datasets well and is fully open-source, but has no dedicated commercial support and the same browser-rooted architecture as Highcharts.SciChart takes a different route. At the core is Visual Xccelerator™, a proprietary C++ engine that renders natively against DirectX, Metal, OpenGL ES, or WebGL depending on the platform — no web-view in the loop, no browser component smuggled into your native app. That architecture is what makes handling up to 1 billion data points possible, backed by dedicated native SDKs for Android, iOS, macOS, WPF, and JavaScript instead of one implementation wrapped six different ways. Licensing is developer-based too, not per-seat or usage-based, so your bill doesn't spike the moment your user count does.For teams evaluating a charting stack, the practical takeaway is to test against your actual constraints - streaming data volume, true native rendering vs. embedded browser, and how licensing costs behave as you grow - rather than picking on ecosystem popularity alone.Curious how that stacks up against Plotly, Highcharts, and ECharts for enterprise-grade apps? Full breakdown here:Source: SciChart Blog — Best Cross-Platform Charting Libraries for Enterprise Apps

Why Enterprise Devs Are Rethinking Cross-Platform Charting
28 days ago

#IT2School: Digitale Bildung und die ING Deutschland 💻 🤖

Wir bereiten junge Menschen auf die Herausforderung von morgen vor und du kannst mit dabei sein.Digitale Technologien 💻 und Künstliche Intelligenz 🤖 verändern unsere Welt rasant. Zusammen mit der Wissensfabrik e.V. möchten wir Informatik an Schulen präsent machen – und Schülerinnen und Schülern zeigen, wie sie früh mitmachen und mitgestalten können 💪Dieses Jahr feiert die Wissensfabrik e.V. zehnjähriges Jubiläum und als Vereinsmitglied nutzen wir diesen Anlass, um über die Zukunft von Schule, Wirtschaft und Wissenschaft zu sprechen. Am 📅 29. September laden wir deshalb in unseren Hauptsitz in Frankfurt ein und freuen uns auf einen Tag voller Impulse und Perspektiven.👉 Habt ihr Lust, mitzudenken und mitzudiskutieren? Dann freuen wir uns auf Euch! Es gibt noch ein paar freie Plätze.

#IT2School: Digitale Bildung und die ING Deutschland 💻 🤖
about 1 month ago

#TeamFI

Bastian DegmayrNetzwerkadministrator Zentrale NetzplattformBastian ist Netzwerkadministrator in der Abteilung Zentrale Netzplattform am Standort Hannover. Er hat sein duales Studium in Wirtschaftsinformatik bei uns absolviert und ist nach dem Studium direkt in seiner Ausbildungsabteilug gestartet. Er erzählt uns, wie das Team zusammen funktioniert, für was er zuständig ist und was er seinem jüngerem Ich raten würde. Wie Bastian seinen Freunden und Familie seinen Job erklärt und was ihn besonders motiviert, erfahrt ihr hier in seiner people story: https://lnkd.in/eYSrBP_x

#TeamFI
about 1 month ago

#TeamFI

Saarlin GopalasingamBusiness Analyst Nutzer- und Berechtigungsmanagement Saarlin ist Anfang 2024 zum #TeamFI als Business Analyst gestoßen. Er bringt viel Berufserfahrung mit und berichtet über seinen Werdegang, einen Auslandsaufenthalt, seinen Bewerbungsprozess bei uns und die ersten Monate in der Finanz Informatik. Ganz besonders lobt er das Miteinander seiner Abteilung und seiner Führungskraft. Er ist hochmotiviert und möchte neue Dinge anpacken - was für ein Spirit! 😎 Die ausführliche Story findet ihr hier: https://lnkd.in/dACQxJzy

#TeamFI
about 1 month ago

#TeamFI

Wafaa HamdanSoftwareentwicklerin im Bereich Professional ServicesMut, Neugier und der Wille, Neues zu lernen – das beschreibt unserer Kollegin Wafaa Hamdan perfekt. ✨Sie erzählt uns, wie sie ihren Weg von Syrien über das Elektrotechnik-Studium bis hin zur Softwareentwicklung bei der FI gefunden hat. Heute bringt sie ihr Wissen und ihre Leidenschaft für KI und Softwarelösungen in spannende Projekte ein und verwandelt komplexe Ideen in greifbare Lösungen. 👉🏽 Eine Geschichte über Veränderung, Fortschritt und Stärke. Die ausführliche Story findet ihr hier: https://lnkd.in/ebK2ajFB

#TeamFI
2 months ago

Top oder Flop: Unsere Young Talents haben entschieden ...

... und ihre ehrliche Meinung bei der unabhängigen Befragung der Fair Company Initiative mit uns geteilt.Young Talents, das sind unsere Praktikantinnen und Praktikanten, Werkstudierende, Trainees, Azubis, Dual Studierende und Young Professionals. Alle waren zwischen Januar 2025 und Januar 2026 Teil unseres Teams.Die Ergebnisse zeigen, das unsere Kultur funktioniert und das Feedback macht uns stolz! 👉 Du stehst am Anfang deiner Karriere und möchtest wissen, welche Möglichkeiten dich bei uns erwarten? Schau gerne auf unserer Karriere-Website vorbei und entdecke unsere Einstiegsmöglichkeiten.

Top oder Flop: Unsere Young Talents haben entschieden ...
2 months ago

From coding to orchestrating

Developers are doing less coding than you think.What happens when AI stops assisting and starts acting?Agentic development is changing how software gets built. Instead of writing every line of code, developers increasingly define problems, set boundaries and guide AI systems that can execute and improve on their own.In this article, Viktor Van Steenweghen shares how his role is evolving in practice. From running multiple AI agents in parallel to focusing more on orchestration than execution, his experience offers a clear view of where development is heading.The biggest shift is not technical, it is mental.Explore how the role is changing: https://lnkd.in/euhTJy7X

From coding to orchestrating
3 months ago

Auf den Schultern von Riesen

Ernst Weichselbaum starb am 27. Dezember 2024, zwei Tage nach Weihnachten. Er wurde 80 Jahre alt. Der österreichische Berater, Philosoph und Pionier zeitorientierter Arbeitssysteme hinterließ ein Werk, das fast niemand in der Softwareentwicklung gelesen hat. Er hinterließ zudem den OK-Punkt – ein Konzept, das mehr als sieben Jahrzehnte nach Taiichi Ohnos ersten Experimenten bei Toyota endlich den Weg in den Bereich gefunden hat, in dem es am dringendsten benötigt wird.In diesem Artikel geht es um die Linie, die von Toyota City in den 1950er Jahren über Wien in den 1980er Jahren bis hin zum OK Point führt, wie wir ihn heute kennen: den täglichen Austausch zwischen Konzeptentwicklern und Umsetzern im Herzen der zeitorientierten Softwareentwicklung. Es geht auch darum, warum diese Linie 70 Jahre gebraucht hat, um uns zu erreichen, und warum es wichtig ist, dass wir anerkennen, auf wessen Schultern wir stehen.Die Entdeckung in Toyota CityTaiichi Ohno wurde 1912 in Dalian an der mandschurischen Küste geboren. Er trat als junger Ingenieur bei Toyota Spinning and Weaving ein und wechselte 1943 zur Toyota Motor Company. In den folgenden drei Jahrzehnten entwickelte er – fast im Verborgenen – das, was später als „Toyota-Produktionssystem“ bekannt werden sollte: eine Reihe von Methoden, die so radikal waren, dass westliche Führungskräfte, die Toyotas Fabriken besichtigten, jahrelang mit dem Eindruck zurückkehrten, ihnen entginge etwas. Und das tat es auch.Das, was ihnen fehlte, war einfach zu beschreiben, aber fast unmöglich zu verinnerlichen. Ohno hatte die grundlegende Annahme der industriellen Produktion auf den Kopf gestellt. Im Westen ging man davon aus, dass die Kapazität feststeht – man hat seine Maschinen, seine Arbeiter, seine Arbeitszeiten – und die Lieferzeit schwankt um diese herum. Steigt die Nachfrage, werden die Warteschlangen länger, die Kunden warten. Sinkt die Nachfrage, stehen die Maschinen still, werden Arbeiter entlassen. Die Kapazität ist die Konstante; die Zeit ist die Variable.Ohno tat das Gegenteil. Er legte die Zeit fest und ließ die Kapazität schwanken. Er konzipierte Toyota so, dass die Produktion mit gleichmäßigen, zuverlässigen Lieferungen – der berühmten Taktzeit – auf die Kundennachfrage reagierte und sich die Kapazität des Systems selbst anpasste, um diesen Rhythmus aufrechtzuerhalten. Wo sich die Kapazität nicht anpassen ließ, gestaltete Ohno sie so, dass sie umgestaltet werden konnte. Multifunktionale Mitarbeiter. Schnellwechselwerkzeuge. Kleine Losgrößen. Pull statt Push. Das Ergebnis war in den 1970er Jahren ein Fertigungssystem, das Autos in einer Qualität und zu Kosten produzieren konnte, mit denen westliche Autohersteller nicht mithalten konnten, ohne die zugrunde liegende Philosophie zu kopieren. Die meisten von ihnen versuchten, nur die äußeren Merkmale zu kopieren – die Kanban-Karten, die Andon-Schnüre – und scheiterten.Ohno hat die grundlegende Erkenntnis aller Zeitorientierung erkannt: Die Welt schwingt. Die Nachfrage schwingt. Die Jahreszeiten schwingen. Die Erde schwingt. Arbeitssysteme aufzubauen, die so tun, als wäre dies nicht der Fall, bedeutet, gegen die Physik zu arbeiten. Arbeitssysteme aufzubauen, die mit der Welt schwingen, bedeutet, mit ihr zu arbeiten.Der Philosoph, der die Fackel trugOhno war ein Praktiker. Er war zudem, allen Berichten zufolge, ein schwieriger Mensch – direkt, unverblümt und intolerant gegenüber der ausweichenden Sprache, die den Großteil des Managementdenkens umgibt. Er verfasste drei Bücher, von denen eines ins Englische übersetzt wurde. Er starb 1990, nachdem er miterlebt hatte, wie das Toyota-Produktionssystem weltberühmt und fast überall missverstanden wurde.Etwa zur gleichen Zeit, als westliche Berater damit beschäftigt waren, TPS in „Lean Manufacturing“ umzuwandeln – eine freundliche, vermarktbare, etwas entschärfte Version von Ohno’s Werk –, war in Österreich ein Denker ganz anderer Art am Werk. Ernst Weichselbaum war ein Berater, der Jahrzehnte in produzierenden Unternehmen verbracht hatte, wo er mit den von Ohno entwickelten Systemen arbeitete, dabei aber andere Fragen zu ihnen stellte. Weichselbaum war ein Philosoph im älteren Sinne des Wortes: jemand, der versuchte, die Prinzipien hinter der Praxis zu verstehen, und nicht jemand, der diese Praktiken in Schulungen verpacken wollte.Weichselbaums einzigartiger Beitrag, auf den wir bei TOSD täglich zurückgreifen, war der „OK-Punkt“. In seiner ursprünglichen Formulierung befand sich der OK-Punkt an der Schnittstelle zwischen Kunde und Lieferant. Es war der Moment der Einigung – konkret, bezeugt, oft physisch –, in dem ein Projekt von der Konzeptphase, in der die Anforderungen noch verhandelbar waren, in die Umsetzungsphase überging, in der dies nicht mehr der Fall war. Vor dem OK-Punkt konnten beide Seiten noch darüber sprechen, wie die Arbeit aussehen sollte. Danach verlagerte sich das Gespräch darauf, ob die Arbeit wie vereinbart ausgeführt wurde. Der OK-Punkt war der Moment, in dem Transparenz unvermeidlich wurde: nicht, weil jemand sie erzwang, sondern weil das Überschreiten dieses Punktes beide Parteien an dieselbe gemeinsame Definition von „fertig“ band.Weichselbaum erkannte, was Ohno erkannt hatte – dass der Wert der Zeitorientierung nicht in der Geschwindigkeit liegt, sondern in der Disziplin, die die Zeitorientierung schafft. Doch er dehnte Ohnos Erkenntnis nach innen aus, vom Fließband hin zum Gesprächsgeschehen. Der OK-Punkt ist eine zeitliche Struktur, die in einer Beziehung zwischen zwei Parteien existiert. Das ist auch der Grund, warum sich Zeitorientierung anders anfühlt als Lean: Lean versucht, Verschwendung zu beseitigen, Zeitorientierung versucht, Rhythmus zu gestalten.Weichselbaum widmete seine Karriere der Einführung von Zeitorientierung in Unternehmen, die noch nie von Toyota gehört hatten. Er arbeitete mit produzierenden Unternehmen zusammen, aber auch mit Organisationen im Bereich der Wissensarbeit. Er verfasste nur wenige Schriften. Das meiste, was wir über sein Denken wissen, stammt von den Menschen, die er beeinflusst hat – darunter Niels Pflaeging, der den kürzlich erschienenen Band „What would Ernst Weichselbaum do?“ herausgegeben hat und der mehr als jeder andere dafür gesorgt hat, dass Weichselbaums Name nicht in derselben Anonymität verschwindet, die so viele von Ohno’s tatsächlichen Mitarbeitern umgab.Die 70-jährige LückeHier ist die Frage, die uns beschäftigt hat, während wir TOSD aus diesem Erbe aufgebaut haben: Warum hat es 70 Jahre gedauert, bis die Zeitorientierung die Softwareentwicklung erreicht hat?Die ehrliche Antwort lautet: Die Softwareentwicklung hat sich dagegen gewehrt. Sie hat sich aus Gründen gewehrt, die bei nüchterner Betrachtung wenig schmeichelhaft sind. Der erste und am weitesten verbreitete Grund war die Überzeugung, dass Software Kunst sei. Durch diese Einordnung in den Kunstkontext fühlte sich jeder Versuch, der Entwicklung eine zeitliche Struktur zu geben, wie ein Verstoß gegen die kreative Integrität an. Außerdem entband sie die Branche bequemerweise von der Disziplin, die andere Bereiche des Ingenieurwesens längst akzeptiert hatten. Die kapazitätsorientierte Herangehensweise mit ihren langen Planungshorizonten und ihrer Toleranz gegenüber Terminüberschreitungen passte perfekt zu einer Praxis, die im Kunstkontext verortet war. Die zeitorientierte Herangehensweise tat dies nicht.Der zweite Grund war, dass die frühe Agile-Bewegung um das Jahr 2001 herum die eine Hälfte von Ohno’s Erkenntnis aufgriff und die andere Hälfte verwarf. Das Agile Manifest und die Methoden, die sich darum herum entwickelten – Scrum, dann Kanban, dann die Skalierungs-Frameworks – übernahmen den „Small-Batch“-Ansatz aus Lean und nannten ihn „Iteration“. Aber sie behielten die Kapazitätsorientierung als zugrunde liegenden Rahmen bei. Ein Scrum-Team hat eine feste Kapazität, ausgedrückt in Story-Points, von der angenommen wird, dass sie stabil ist. Sprints kommen und gehen; was schwankt, ist das, was in sie hineinpasst. Das ist die Wand, die mit einer anderen Farbe gestrichen wurde. Ohno hätte darin keine Zeitorientierung erkannt.Der dritte Grund war soziologischer Natur. Zeitorientierung führt zu einer Dezentralisierung der Macht. Sie lässt sich nicht mit der dichten Schicht von Vermittlerrollen – Product Owner, Scrum Master, Agile Coaches, Projektmanager, Architekten im Titel – vereinbaren, die sich in den letzten zwei Jahrzehnten rund um die Softwareentwicklung gebildet hat. Eine ganze Branche hat sich um die Aufrechterhaltung dieser Rollen herum organisiert. Zeitorientierung bedeutet unter anderem das Verschwinden dieser Branche. Wie zu erwarten war, hat die Branche diese Entwicklung nicht gerade begeistert aufgenommen.Der vierte und vielleicht entscheidende Grund war, dass KI die Rechnung verändert hat. Bevor KI-Assistenten ins Spiel kamen, war der Aufwand beim Tippen von Code so groß, dass die Kapazitätsorientierung vorgeben konnte, das richtige Modell zu sein. Sobald die KI den Aufwand für das Tippen auf nahezu null senkte, verlagerte sich der Engpass. Er verlagerte sich zum Denken – zur Präzision dessen, was gebaut wird, bevor es gebaut wird. Ein Bereich, in dem der Engpass die Präzision ist, ist ein Bereich, der einen OK-Punkt benötigt. Die Software hatte schließlich keinen Ort mehr, an dem sie sich verstecken konnte.Die Übertragung auf TOSDIm White Paper Nr. 26 beschreiben wir den „OK-Punkt“ in der Softwareentwicklung. Die Übertragung von Weichselbaums „Kunde-Lieferant-Nahtstelle“ ist nicht metaphorisch gemeint: Die Struktur ist dieselbe, nur die Parteien sind andere. In TOSD ist der „OK-Punkt“ die Nahtstelle zwischen Konzeption und Realisierung. Der Konzeptionist übernimmt die Rolle der konzeptionellen Seite; der Realisierer übernimmt die Rolle der realisierenden Seite. Der Handschlag ist ein tägliches Ritual, kein vertragliches, aber der zugrunde liegende Mechanismus – es wird eine Einigung erzielt, die Einigung wird bezeugt, die Arbeit überschreitet eine Schwelle – entspricht dem, was Weichselbaum beschrieben hat.Wir haben auch den von Ohno entdeckten Rhythmus fast unverändert übernommen. Tägliche Portionen sind die Kadenz des Fließbandes in der Softwareentwicklung. Die Zeitbox der Realisierung (ein, zwei oder drei Tage) ist die kleine Charge. Das TTEO-Prinzip – „Talk To Each Other“ (Miteinander reden) – ist die Andon-Schnur, an der jederzeit gezogen wird, wenn etwas nicht stimmt. Das Zellstruktur-Design ist in vielerlei Hinsicht die Philosophie der vielseitig qualifizierten Arbeitskräfte, angewandt auf eine gesamte Organisation. Das sind keine Zufälle. Es sind die strukturellen Grundsätze jedes zeitorientierten Arbeitssystems, übertragen auf einen Bereich, den Ohno nie gesehen hat und den Weichselbaum sich erst zu erahnen begann.Warum die Tradition wichtig istEs wäre einfach und verlockend, TOSD als etwas Neues darzustellen. Aus marketingtechnischer Sicht ist es das auch. Aus intellektueller Sicht ist es jedoch der jüngste Ausdruck eines 70-jährigen Projekts. Ich halte diese Unterscheidung aus mindestens drei Gründen für wichtig.Erstens verschafft die Tradition jedem, der TOSD anwendet, Zugang zur umfassenderen Fachliteratur. Wenn Sie sich damit schwertun, wie die Kapazität in Ihrer Organisation schwanken sollte, müssen Sie die Antwort nicht von Grund auf neu erfinden – Ohno hat diese Frage bereits ausführlich für einen Bereich beantwortet, der schwieriger ist als der Ihre. Wenn Sie sich damit schwertun, wie sich der „OK-Punkt“ in der Praxis anfühlt, können Sie Weichselbaum lesen und seine ursprüngliche Formulierung nachschlagen. Die Menschen von diesem Erbe abzuschneiden, indem man so tut, als sei TOSD im Oktober 2025 erfunden worden, würde die Praxis verarmen lassen.Zweitens schützt die Herkunft vor der häufigsten Fehlerquelle neuer Methoden, nämlich der stillschweigenden Wiedereinführung alter Annahmen. Die Zeitorientierung wurde sieben Jahrzehnte lang kontinuierlich abgelehnt, neu interpretiert und wieder vereinnahmt. Die Kenntnis der Geschichte hilft Ihnen, die Muster zu erkennen, wenn sie bei TOSD auftreten. Und das werden sie.Drittens, und das ist das Wichtigste: Diese Tradition mahnt uns zur Demut. Ohno starb, bevor er erleben konnte, dass seine Arbeit richtig verstanden wurde. Weichselbaum starb, bevor er erleben konnte, dass seine Arbeit in Software Einzug hielt. Das Mindeste, was wir tun können, um diese Linie um ein weiteres Segment zu verlängern, ist, die Menschen zu nennen, deren Erkenntnisse wir in die Praxis umsetzen. Das Whitepaper Nr. 26 ist Weichselbaum gewidmet. Das Whitepaper Nr. 27 ist Ohno gewidmet. Jeder, der TOSD nutzt, hält – ob er es weiß oder nicht – diese Linie ebenfalls am Leben.Wir hoffen, dass zukünftige Praktiker sie weiter ausbauen werden. Ich hoffe, dass jemand im Jahr 2050 auf unsere heutige Darstellung zurückblicken und sie als primitiv empfinden wird – nicht, weil sie falsch war, sondern weil sieben Jahrzehnte weiterer Arbeit sie so erscheinen lassen. So funktionieren schließlich Traditionen.Erfahren Sie mehr über TOSD: https://timeoriented.dev

Auf den Schultern von Riesen
3 months ago

Strong team performance — the first joint B2Run for the synava group

Software development is about solving challenges together. The B2Run Karlsruhe offered a different kind of challenge: a 5.5 km running course through Karlsruhe.Runners from IT-Choice Software GmbH, medavis GmbH, and synava came together as one synava group team. All with different roles, different expertise and experience. The 5.5 km course wasn’t about finishing times. It was about collaboration, mutual support, and the energy that comes from working toward a shared goal.Moments like these remind us that strong teams are built not only through projects, but through shared experiences.One of the highlights: after the run, there was plenty of time to connect, celebrate together, and enjoy the great atmosphere at the team tent - all with perfect weather ☀️ and lots of positive energy.For us, events like these matter. They create connections across teams, strengthen relationships, and remind us that behind every successful software solution is a group of people who enjoy achieving great things together.

Strong team performance — the first joint B2Run for the synava group
3 months ago

Vielfalt entfalten. Happy Pride 2026!

Pride Month bei der ING bedeutet mehr als Flagge zeigen. 🌈 🧡 Für uns sind Diversity, Inclusion & Belonging keine Buzzwords, sondern gelebter Bestandteil unserer Kultur. Sie sind Teil unserer Haltung und prägen unser tägliches Miteinander: ing.de/miteinandersUnser Ziel ist eine Unternehmenskultur, in der alle bei der Arbeit sie selbst sein können. Niemand soll Energie damit verschwenden müssen, sich zu verstellen, oder das Gefühl haben, einen Teil von sich verstecken zu müssen.Zeigs uns und werde Teil der ING: Wir sind auf der Suche nach diversen Köpfen, die uns vielfältiger und bunter machen. Wenn Vielfalt und Inklusion auch Teil Deiner Haltung sind, dann haben wir vielleicht genau den Job, der zu Dir passt: Karriere bei der ING.

This content is not shown due to your cookie preferences.

3 months ago

Spring IO 2026

Inspiration, Innovation und jede Menge Tech-Insights!Wir waren mit einem Team der tree-IT GmbH auf der Spring I/O in Barcelona — einer der spannendsten Konferenzen rund um moderne Softwareentwicklung, Cloud, AI und Java-Technologien.Neben spannenden Talks und technischen Deep Dives konnten wir viele neue Impulse für unsere Projekte und Produkte mitnehmen.Danke an die Community, die Speaker und alle spannenden Gespräche vor Ort #SpringIO #SoftwareEngineering #Java #SpringBoot #AI #Cloud #DevOps #treeIT #DesignBuildShip

Spring IO 2026
3 months ago

Turn your backend into an MCP server without writing MCP server code

Graftcode is coming to WeAreDevelopers as a Bronze Partner, and you can attend our workshops on Day 0 and visit us in Hall A, opposite Stage 11.With Graftcode Gateway, developers can expose backend methods directly to LLM agents through MCP - without adding a separate MCP layer, wrapper file, decorators, or protocol-specific code.Run your application with Graftcode Gateway, and it automatically detects your public backend methods and exposes them as tools that agents can call. Your business logic stays clean. Your code does not need to know it is being used by an LLM agent.One of our users recently wrote about this exact experience: after removing 30 lines of MCP server code, their Claude Desktop agent still worked.The reason is simple: Graftcode Gateway handles the MCP exposure outside your application code.We believe this is the right direction for agent-ready software:less boilerplate, fewer duplicate interfaces, and one clean source of truth - your actual backend code.Meet us at our booth and see how Graftcode lets LLM agents talk to your code directly.

Turn your backend into an MCP server without writing MCP server code
3 months ago

React Memory Leaks: How to Find Them, Fix Them, and Prevent Performance Issues

What causes memory leaks in React apps?A React memory leak happens when your app keeps references to data, DOM nodes, or processes that should have been cleaned up. Over time, memory usage grows, performance drops, and longer sessions may end in a crashed tab.In most cases, leaks don’t come from a single bug. They come from small things that accumulate as components mount and unmount.Common causes of memory leaks in ReactThese are the patterns developers run into most often:Event listeners not removed — attached to window or document, but never cleaned up after unmount.Timers still running — setInterval or setTimeout continues executing after the component is gone.Unclosed subscriptions — WebSockets, data streams, or observables continue pushing updates in the background.Closures holding large data — functions retain references to variables from outer scope, preventing the garbage collector from reclaiming memory.Async updates after unmount — a request resolves and calls setState on a component that no longer exists.Missing disposal in third-party libraries — some rendering engines (WebGL, WebAssembly, charting libraries) require explicit .dispose() or .delete() calls.How to fix memory leaks in ReactMost React memory leaks are solved the same way: clean up side effects properly.If you use useEffect, anything that creates a side effect should also remove it:useEffect(() => { const interval = setInterval(() => { updateData(); }, 1000); return () => { clearInterval(interval); };}, []);The rule is simple: If your effect starts something, it should also stop it.How to detect memory leaks in React1. Use Chrome DevTools (Memory tab)Take a Heap Snapshot as a baselineTrigger the behaviour (e.g. navigate, mount/unmount components)Force garbage collectionTake a second snapshotCompare the twoFocus on:Objects that increase but don’t go awayDetached DOM nodes (elements no longer in the UI but still in memory)2. Use the Performance tabA healthy app → memory rises and dropsA leaking app → memory rises and never fully dropsReact memory leak checklist (quick audit)Do all useEffect hooks return cleanup functions where needed?Are event listeners removed on unmount?Are timers cleared?Are WebSocket or stream connections closed?Are requestAnimationFrame loops cancelled?Are fetch requests aborted when components unmount?Are large datasets scoped correctly?Do third-party libraries provide a dispose/delete method — and are you calling it?Are you preventing state updates on unmounted components?Have you compared heap snapshots before and after reproducing the issue?Why memory leaks get worse in data-heavy appsIf your app handles large or real-time datasets, leaks become more noticeable.Some libraries keep large datasets in JavaScript memory. If references persist, the garbage collector cannot reclaim that memory.At that scale, memory management isn’t just an implementation detail — it’s part of your architecture.In short:Most React memory leaks come from uncleaned side effects in useEffectThe common causes are listeners, timers, subscriptions, and async updatesUse Heap Snapshots in Chrome DevTools to confirm leaksData-heavy apps amplify the problemA simple cleanup habit prevents most issuesMemory leaks are rarely mysterious. They’re usually leftover work that never got cleaned up.React won’t manage that for you — but once you know where to look, leaks are predictable and fixable.

React Memory Leaks: How to Find Them, Fix Them, and Prevent Performance Issues
4 months ago

WPF vs Avalonia: Which Should .NET Developers Choose in 2026?

For .NET desktop developers, the choice between WPF and Avalonia depends mainly on platform strategy.WPF is still a strong choice for Windows-only enterprise applications. It is mature, stable, deeply integrated with the Windows ecosystem, and supported by years of Visual Studio tooling, documentation, third-party controls, and production use.Avalonia is designed for modern cross-platform .NET desktop development across Windows, macOS, and Linux. It uses Skia and multi-backend rendering, giving developers more flexibility when applications need to run beyond Windows.For new cross-platform applications, Avalonia UI can be a strong option. It feels familiar to XAML developers while offering broader platform reach.For teams with existing WPF applications, Avalonia XPF is especially relevant. It is a commercial WPF compatibility layer built on Avalonia that allows existing WPF apps to run on macOS and Linux with minimal code changes.For advanced data visualization, the UI framework is only part of the stack. Real-time telemetry, financial dashboards, scientific applications, and other data-intensive systems often depend more on the rendering engine than the windowing framework.SciChart supports both WPF and Avalonia XPF, helping developers maintain high-performance, real-time data visualization while choosing the platform strategy that fits their application.In short:Choose WPF if you are Windows-first and need maturity, tooling, and proven enterprise stability.Choose Avalonia UI for new cross-platform .NET desktop applications.Choose Avalonia XPF if you need to move an existing WPF application beyond Windows with minimal code changes.Read the full technical blog:https://www.scichart.com/blog/wpf-vs-avalonia/

WPF vs Avalonia: Which Should .NET Developers Choose in 2026?
4 months ago

#WellbeING: Sicherheit und Gesundheit bei der ING – auch mental!

Kein Tabu um mentale Gesundheit am Arbeitsplatz. Lasst uns darüber sprechen. 🧡Zum 🌍 Welttag für Sicherheit und Gesundheit am Arbeitsplatz positionieren wir uns für Dich mit mehr als ergonomischen Stühlen und Tischen. Überlastung, Stress und Erschöpfung sind nicht immer sichtbar – und gerade deswegen möchten wir darüber sprechen.Bei der ING Deutschland unterstützen wir mit Formaten wie Selbsthilfeangeboten zu Stress, Trauer und Burnout, einem Gesundheitsbudget, präventive Coachings zu Resilienz sowie Ersthelfende für psychische Gesundheit.Denn: Jede 5. Person erlebt im Laufe ihres Lebens eine psychische Erkrankung wie Depression, Burnout oder Angststörung.Du möchtest mehr über unsere WellbeING-Initiative erfahren? Auf unserer Karriereseite findest Du alle unsere löwenstarken Benefits 🦁

#WellbeING: Sicherheit und Gesundheit bei der ING – auch mental!
4 months ago

Which JavaScript Chart Library is Fastest? We Benchmarked 8 of Them.

Developers evaluating charting libraries for high-performance applications ask the same question: which one actually holds up under real data loads?We built an open-source benchmark to find out.What is Chart Bench?Chart Bench is an open-source JavaScript chart performance benchmark suite that stress-tests popular charting libraries across 13 test cases - including line, scatter, heatmap, candlestick, 3D surface, and multi-chart scenarios.It measures:Frames per second (FPS)Time to first render (init time)Memory usageData ingestion rate (points/sec)The benchmark is designed to simulate extreme workloads: millions of data points, real-time streaming, and multiple charts on screen.It runs locally on your hardware, logs results, and allows JSON export for sharing or comparison.Clone and run it:https://github.com/abtsoftware/javascript-chart-performance-test-suiteLibraries TestedSciChart.jsLightningChart.js (v4 + v8)Plotly.jsHighchartsChart.jsApache EChartsuPlotChartGPUWhat It MeasuresFPS under increasing data loadsTime to first render (ms)Memory usage (JS heap)Data ingestion rate (points/sec)Failure conditions: hangs, freezes, crashesOne Number Worth KnowingIn internal benchmark runs, SciChart.js reached ~40 million data points per second ingestion rate and led in FPS across a majority of tested scenarios on a range of hardware.Full results - across multiple hardware configurations from high-end GPUs to low-power devices - are published here:https://www.scichart.com/blog/chart-bench-compare-javascript-chart-libraries/SciChart is a high-performance charting library for JavaScript, WPF, iOS, and Android, designed for real-time, large-scale data visualisation using GPU-accelerated rendering. https://www.scichart.com

Which JavaScript Chart Library is Fastest? We Benchmarked 8 of Them.
4 months ago

Muss ein Karriereweg wirklich geradlinig sein? Nö!

Bei uns muss eine Karriere kein vorgezeichneter Weg auf einer Treppe mit klar markierten Stufen sein. Du entscheidest, was Du aus unseren Angeboten und Deinen Möglichkeiten machst – und ob Du überhaupt auf eine Treppe kraxeln möchtest. Sanja hat bei uns als Praktikantin angefangen und ist inzwischen Vice President Corporate Lending. Ihr Zitat bringt es auf den Punkt: "Die Karriereleiter bei der ING ist, was Du daraus machst."Du bestimmst selbst, welche Schritte für Dich sinnvoll sind, welche Richtungen Du einschlägst und wo Du bewusst Neues ausprobierst.Sanja ist nur ein Beispiel von vielen, die gezeigt haben: Karriere muss nicht planbar aussehen, um richtig gut zu sein. Am Ende zählt, dass Du Deinen eigenen Kurs fährst – auch wenn der mal eine Schleife dreht. 👉 Neugierig? Dann schau auf unserer Karriere-Seite vorbei. Vielleicht wartet Dein nächster Move schon dort: Karriere Website

Muss ein Karriereweg wirklich geradlinig sein? Nö!
4 months ago

Technoly - Lufthansa Premium Partner

A proud moment for Technoly! 🏆Last week, our Managing Directors Stephan and Alexander had the honor of accepting the Lufthansa Premium Partner award on behalf of our entire team - recognizing Technoly as one of the very first Premium Technology Partners worldwide.This makes Technoly one of the very first Lufthansa Premium Technology Partners worldwide. A clear, performance-based framework for the NDC ecosystem, where we earned points for NDC functionalities implemented, technical performance and engagement among other dimensions.

Technoly - Lufthansa Premium Partner
5 months ago

POTTHOFF + PARTNER develops software that makes a difference in Healthcare

Since 1985, POTTHOFF + PARTNER has been operating as an innovative software company in the healthcare sector. Deep expertise in healthcare and software development, and more than 190 successful installations reflect the high quality and reliability of our solutions.Digitalization offers significant potential to optimize clinical processes across both administrative and medical domains. As a specialist in clinical software, we create the technical foundation needed to standardize and streamline workflows in healthcare environments.With KOS, paper-based processes are transformed into efficient digital workflows, accelerating daily operations in clinics. Our mobile solutions already enable a wide range of tasks to be carried out digitally and on the move. Modern applications support staff across all departments—including medical care, therapy, diagnostics, and administration.The KOS | ME patient portal actively integrates patients into clinical processes, establishing a new level of connectivity and engagement.As part of the synava Group, we combine engineering depth with a broader healthcare IT ecosystem. We develop on a state-of-the-art stack—cloud-ready where it belongs, API-first by instinct—and we put AI to work where it truly moves the needle: faster iteration, sharper quality gates, and assistive intelligence that amplifies clinicians and staff while keeping accountability human. Together with experienced consultants and application specialists, we translate clinical and operational needs into thoughtful releases, clear interfaces, and user experiences that give on-site teams confidence—from documentation and billing to digitally supported workflows across the clinics.Why this matters in practiceWe do not build software in an ivory tower; we refine it in dialogue with clinical routine. That alignment reduces friction between departments, harmonizes how teams work, and turns improvement into something you can feel where it counts—for everyone who relies on KOS every day.More momentum. More intelligence. More impact.

POTTHOFF + PARTNER develops software that makes a difference in Healthcare
5 months ago

The future of Software Development is quite clear

Seeing Cursor 3 introduce a new agentic workflow really reinforces something we (and IT market) have been thinking about for a while:Developers are gradually becoming orchestrators.Not in the sense that they stop building, but in the sense that more of the job becomes guiding, reviewing, connecting, and shaping what agents produce.And we think that changes a lot about how we should write software.If developers are going to spend more time reading code generated by agents than writing every line themselves, then readability becomes much more important than before. The code has to be easy to follow, easy to reason about, and easy to verify.Honestly, the same is true for AI. The clearer the codebase is, the easier it is for agents to work inside it without creating unnecessary mess.That’s also one of the reasons we’re building Graftcode the way we are.We want code to stay focused on business logic, not get buried under all the complexity of how services talk to each other. When that communication layer is less intrusive, the result is simply easier to understand - both for developers and for AI.We think this will matter more and more over time.The future is probably not just developers writing code.It’s developers directing systems of agents.And in that world, clear code is a huge advantage.Check out link in the comment, and see how Graftcode can help you and AI focus on the business logic.

The future of Software Development is quite clear
6 months ago

Wo wir arbeiten

Unser Büro ist ausgezeichnet!Unser Büro wurde vom Callwey Verlag als einer der „Best Workspaces 2026“ ausgezeichnet und in das gleichnamige Jahrbuch aufgenommen. Damit gehört unser Pradtke HQ jetzt auch offiziell zu den herausragenden Arbeitsorten des Jahres 2026. Für uns ist diese Auszeichnung weit mehr als ein Designpreis. Sie bestätigt unsere Überzeugung, dass Räume nicht Kulisse sind, sondern ein integraler Bestandteil organisationaler Wirksamkeit. Arbeitsräume prägen Verhalten, Zusammenarbeit und Kultur.Unser Büro sieht nicht nur gut aus, sondern fühlt sich auch so an: Es gibt uns viel Raum für kollegiale Kommunikation, konstruktive Konzentration, für unsere Kunden und für Kulinarik. Denn alle, die im Büro sind, begegnen sich jeden Tag bei einem gemeinsamen Mittagstisch, zu dem wir uns selbst einladen.

Wo wir arbeiten
6 months ago

TIME IS THE NEW FRAMEWORK

Wie TOSD die Softwareentwicklung revolutioniertInterview mit Sebastian Kubsch, CTO der Pradtke GmbHSebastian, du bist CTO der Pradtke GmbH und hast gemeinsam mit Niels Pfläging den Entwicklungsprozess TOSD »erfunden.« Was steckt hinter »Time-Oriented Software Development?«Sebastian: TOSD ist ein radikal neuer Ansatz für Softwareentwicklung, der Zeit als zentrale Ressource betrachtet – nicht im Sinne von Deadlines, sondern als integralen Bestandteil der Zusammenarbeit, Planung und Umsetzung. Statt klassischer Projektpläne oder Sprint-Zyklen setzen wir auf konsequente Zeitorientierung, die den natürlichen Rhythmus von Arbeit, Teams und Organisationen berücksichtigt. Das führt zu mehr Klarheit, weniger Overhead und einer deutlichhöheren Anpassungsfähigkeit.Wie kam es zur Zusammenarbeit mit Nils Pfläging und zur Entwicklung von TOSD?Sebastian: Niels und ich haben uns im Sommer 2024 im Rahmen unserer der Beta-Transformation bei Pradtke kennen und mögen gelernt. Wir teilen die Leidenschaft für dezentrale, agile Organisationsformen. In vielen Gesprächen haben wir festgestellt, dass »klassische« Softwareprozesse – auch so genannte »agile« Formen der Softwareentwicklung – oft nicht zu modernen, dynamischen Unternehmen passen. Aus dieser Erkenntnis heraus haben wir TOSD entwickelt – als Antwort auf die Herausforderungen, die wir selbst erlebt haben. Es war ein intensiver, kreativer Prozess, der Theorie und Praxis miteinander verbunden hat.Du bist als CTO bei Pradtke der Allererste, der jemals TOSD eingeführt hat. Wie verlief die Implementierung und was waren die größten Learnings dabei?Sebastian: Die Einführung war ein spannender Schritt. Wir haben TOSD nicht einfach »ausgerollt«, sondern gemeinsam mit unseren Teams erarbeitet und angepasst. Das hat enorm geholfen, hohe Akzeptanz zu schaffen und zügig echte Wirkung zu erzielen. Besonders beeindruckt hat mich, wie schnell sich die Kommunikation verbessert hat – weniger Meetings, klarere Entscheidungen, mehr Fokus.Gleichzeitig hat sich die Geschwindigkeit der Entwicklung sofort drastisch erhöht. Ein zentrales Learning war: Wenn man den Menschen vertraut und ihnen die Zeit als Gestaltungsmittel bewusst macht, entstehen großartige Ergebnisse.Welche konkreten Vorteile hat TOSD schon jetzt für eure Kunden gebracht?Sebastian: Unsere Kunden profitieren direkt von der höheren Reaktionsgeschwindigkeit und der besseren Qualität unserer Software. Durch die zeitbasierte Orientierung können wir schneller auf neue Anforderungen reagieren, ohne in Hektik zu verfallen. Das schafft Vertrauen und ermöglicht eine partnerschaftliche Zusammenarbeit auf Augenhöhe.Wie geht es mit TOSD weiter – intern bei Pradtke und darüber hinaus?Sebastian: Wir entwickeln TOSD kontinuierlich weiter, gemeinsam mit unseren Teams –wir lernen immer noch jeden Tag, jede Woche dazu. Gleichzeitig möchten wir den Ansatz auch anderen Organisationen zugänglich machen – durch konkrete Angebote, Veröffentlichungen und vielleicht sogar ein Buch. Wir haben ein Forschungspapier zu TOSD veröffentlicht, außerdem haben wir die 1. Bochumer Konferenz für Zeitorientierte Softwareentwicklung organisiert, die am 21. Mai stattfinden wird.Gleichzeitig arbeiten wir daran, ein internationales Team rund um TOSD zu formen und mehr Teams und Organisationen für die Zeitorientierung zu gewinnen. So haben wir bereits Andreas Schlegel aus Baden-Württemberg und Ernesto Corona aus Argentinien als Mitstreiter für TOSD gewinnen können – unser Ansatz kommt noch in diesem Jahr nach Südamerika.Es ist viel los rund um die Zeitorientierung, aber es macht auch unglaublich viel Spaß.Was würdest du anderen CTOs oder Softwareverantwortlichen raten, die sich für TOSD interessieren?Sebastian: Mein Rat: Denkt Zeit neu. Betrachtet sie nicht als Gegner, sondern als Verbündete. TOSD ist kein starres Framework, sondern ein Denkansatz, der zur sich an eure Realität der Wertschöpfung anpasst und viele Probleme von Steuerung, Arbeitsorganisation, Qualität und Kosten auflöst oder bearbeitbar macht.Wer bereit ist, die übliche Illusion der Planbarkeit und Steuerbarkeit loszulassen und Entwickler:innen Vertrauen zu schenken, wird überrascht sein, wie viel Potenzial in den eigenen Entwicklungsteams steckt.Mehr zur Zeitorientierten Softwareentwicklung (TOSD): www.timeoriented.devTickets für die 1. Bochumer Konferenz für Zeitorientierte Softwareentwicklung: 1. Bochumer TOSD Konferenz - Pradtke GmbH

TIME IS THE NEW FRAMEWORK
6 months ago

KI-gestützte Softwareentwicklung braucht Zeitorientierung - statt neuer Frameworks

Die Software-Entwicklung als Disziplin steht, methodisch wie technologisch, vor großen Herausforderungen. Viele Frameworks für die Organisation der Software-Entwicklung, allen voran Scrum, haben letztlich nie die Wirkung entfaltet, die sich viele erhofft haben. Darauf deuten auch die wenigen belastbaren Studien hin. Es ergibt sich ein „Organizational Drifting“: Prozessuale Anpassungen führen dazu, dass sich die Frage stellt, ob das, was praktiziert wird, überhaupt noch Scrum ist. Der Einsatz von KI-gestützter Codegenerierung wiederum verändert derzeit die Software-Entwicklung nicht nur als Disziplin, sondern auch als Job. Ein viel beobachtetes Phänomen: Mit KI entsteht zwar mehr Code, aber es wird nicht mehr Software ausgeliefert. All das haben wir auch bei Pradke in den letzten Jahren er- und durchlebt. Mit immer wieder einer Konsequenz: Uns ist weniger gelungen, als wir uns vorgenommen haben. Das hat uns dazu gebracht, grundsätzlich zu hinterfragen, wie wir Software-Entwicklung organisieren.Seit Herbst 2025 haben wir, in enger Zusammenarbeit zwischen Niels Pfläging von Red42 und unserem CTO Sebastian Kubsch, Software-Entwicklung neu gedacht und neu gemacht: Mit Zeit- statt Kapazitätsorientierung, als Single-Piece-Flow-System statt im Batch-Processing. Die Resultate sind bereits in der Zwischenbilanz ziemlich beeindruckend: Im Verhältnis zur vorherigen Vorgehensweise – Scrum-ish in Verbindung mit OKR – hat sich der Output vervielfacht: Ein Entwicklungsprojekt, dessen Umsetzungszeit zuvor auf mindestens vier Jahre geschätzt wurde, haben wir in sechs Monaten realisiert. Bei gleicher Teamgröße und ohne Abstriche. Wir haben KI in unsere Arbeitsprozesse integriert, ohne mit den systemischen „Slopware“-Schattenseiten leben zu müssen. Alle bei Pradtke wissen genau, wo wir in der Entwicklung gerade stehen und welche nächsten Features wann ausgeliefert werden. Überschaubare Tagwerke erzeugen für EntwicklerInnen das Erleben von Wirksamkeit und Sicherheit. Das ist toll – und das ist TOSD: Timeoriented Software-Development Dazu haben Niels Pfläging und André Pradke bei Pure Quhr sprechen dürfen. Den Teilnehmenden gebührt unser Dank für das Interesse und die lebhafte Debatte. Wenn Du Lust hat, mit uns gemeinsam entlang von TOSD zu arbeiten, laden wir Dich herzlich ein, uns kennenzulernen und Dich zu bewerben!

KI-gestützte Softwareentwicklung braucht Zeitorientierung - statt neuer Frameworks