Beitrag von triarc laboratories Ltd.

Deine neue Software steht in den Startlöchern und der Go-Live ist geplant. Damit die neue Software auch ein Erfolg wird sollen gewisse Bedingungen geschaffen werden. Was unsere Gedanken dazu sind erfährst Du unten.

Heute (27.3.) um 18:30 Uhr halte ich einen Vortrag auf der JUG Frankfurt über unseren Testansatz bei Chrono24. Die Veranstaltung findet digital statt. Ich freue mich also, den einen oder anderen von euch dort zu sehen 😁   Hier findet ihr weitere Informationen: https://lnkd.in/esaAncmf   Um das hier geht es:   👉 Write tests you love, not hate   Tests sind essenziell, um die langfristige Änderbarkeit eines Softwaresystems sicherzustellen. Allerdings gehört das Schreiben von Tests nicht zu den Lieblingsaufgaben der meisten Entwickler. Insbesondere wenn Tests viel Boilerplate-Code benötigen, sind sie schwer zu schreiben, schwer zu verstehen und schwer zu warten. Bei Chrono24 haben wir darum Tests neu gedacht. Wir haben einen Ansatz entwickelt, der es uns ermöglicht, Tests und Implementierung besser zu entkoppeln. Dadurch befinden sich Tests näher an der Fachlichkeit, sind leichter verständlich und deutlich robuster gegenüber Refactorings. In diesem Vortrag zeigen wir, wie wir die Lesbarkeit von Tests deutlich erhöhen, den Boilerplate-Code auf ein Minimum reduzieren, Tests robust gegenüber Umstrukturierungen gestalten und die Laufzeit der Tests auf ein Minimum verringern konnten.

Detektivarbeit bei der Erneuerung von Bestandssoftware. Niemand mag sie, aber alles steht und fällt damit. Wenn man eine in die Jahre gekommenes Software erneuern möchte, hast du im Prinzip 2 Möglichkeiten. 1) Big Bang Ablöse Neue Software schreiben. Daten übernehmen und die neue Software online bringen. Gleichzeitig die alte Software abdrehen oder auf Read-Only schalten. 2) Iterative Ablöse Beide Systeme werden parallel betrieben. z. B. über eine Echtzeit-Synchronisation oder ein API-Gateway stellst du sicher, dass deine Daten in beiden Systemen landen. Das machst du so lange, bis das neue System das alte vom Featureumfang her abgelöst hat. Dann geht das Alte in Pension. Vor- und Nachteile der beiden Varianten kann man vermutlich tagelang diskutieren (jemand Lust dazu?). Aber jetzt nicht so wichtig. In beiden Fällen sehe ich den wesentlichen Schritt schon davor. Die Vorprojekt-Phase, Discovery Phase, whatsoever. Egal, wie man es nennt. Es geht darum, ALLE Prozesse, die vom Bestandssystem unterstützt werden, zu identifizieren und zu dokumentieren. Wenn so ein System 20 Jahre im Einsatz ist, kommt einiges zusammen und NIEMAND kann sich an alles erinnern.  "Hey, ich habe mir eh die UI angeschaut und mit 3 Mitarbeiter:innen geredet" gilt hier nicht. Da muss man rein in den Code, in die Datenbank usw. Macht man diese Arbeit schlampig, dann garantiere ich dir, geht dieses Projekt ganz gewaltig in die Hose. Kostenüberschreitung Hilfsausdruck. Das Ganze kostet Geld und ist anstrengend. Keine Frage. Und wirkt erst mal beängstigend. Aber am Ende wirst du froh sein, es gemacht zu haben. Versprochen.

Voneinander lernen 👓 Wussten Sie eigentlich schon, dass wir unser Wissen rund um das Thema Application Performance Engineering auch gern teilen? Denn wer sein Wissen teilt, macht sich nicht – wie vielfach befürchtet – obsolet. Etwas zu lesen oder zu hören ist noch lange nicht dasselbe wie es anzuwenden; echtes Wissen wird erst durch eigene Arbeit, Einsatz und Fleiß erworben und gefestigt. Daher ist das #triscon Team gern bereit, in diversen Podcasts und Expert Talks sein Know-How zu präsentieren. Schauen Sie sich doch gern mal auf unserer Website um und erfahren Sie mehr über Themen wie: ☑ Die Auswirkung von Last auf IT-Systeme hautnah erleben ☑ Observability mittels Dynatrace, der Mehrwert für modernes Quality Engineering ☑ Best Practices und Benefits von Lasttesting mit Tricentis NeoLoad im SAP-Umfeld Sie wollen von den Besten lernen? 😉 Dann geht's hier lang: https://lnkd.in/dH5kpJKR #software #testing #softwaretesting #monitoring #observability #softwarequality #qualityassurance #softwareengineering #softwaretests #cloudmigration #cloudnative #cloud #dynatrace #tricentis #neoload #lasttest #loadtesting #performance #engineering

Wird Software immer mehr zur Abofalle? 💰 Software as a Service oder auch “Miete” von Software wird immer präsenter. Das gefällt nicht jedem da draußen. Doch die Tage, wo Unternehmen sich durch Einmalkäufe eine Software angeschafft haben sind gezählt. Und das ist gut so. Warum? Ganz einfach: Durch die fortlaufende Wartung der Software wird diese immer up-to-date gehalten. Sicherheitslücken werden geschlossen und Fehler (meist) rasch behoben. Gerade in einem solch dynamischen Umfeld hat niemand etwas davon, auf starre Lösungen zu setzen. Was ist eure Meinung zu Software-as-a-Service Modellen? ⬇️ #software #abo #IT

Was ist das wichtigste Kriterium bei der Entwicklung einer Software? Dass sie so nah wie nur möglich an den Bedürfnissen der tatsächlichen Nutzer ausgerichtet und gebaut wird. Was es dafür braucht? Gespräche. Erfahrungsaustausch. Zeit. Diskussion. Was Sie tun können? Nehmen Sie sich kurz Zeit und sprechen Sie mit uns über Ihre Erfahrungen, oder füllen Sie unsere fertige Umfrage aus. https://lnkd.in/g-EdWaMP Lieben Dank vorab!

🔥 Stellen Sie sich vor: Das Bereitstellen von Testumgebungen geht plötzlich bis zu 70 % schneller und der Speicherbedarf schrumpft um satte 80 %.  Diese Zahlen aus unserem aktuellen Whitepaper verdeutlichen die Effizienzvorteile einer gezielten Auswahl relevanter Datenabschnitte für Testzwecke. Gerade in der Softwareentwicklung entscheidet die Geschwindigkeit über Erfolg und Misserfolg eines Produkts – solche Effizienzsteigerungen sind entscheidend.  1️⃣ Optimierte Ressourcennutzung 👉 Selektive Testdaten reduzieren den Speicherbedarf erheblich. 👉 Bereitstellungszeiten für Testumgebungen können um bis zu 70 % verkürzt werden. 2️⃣ Kosteneffizienz 👉 Deutliche Reduzierung der Speicheranforderungen um bis zu 80 %, was die Kosten senkt. 👉 Verringerte Vor- und Nachbearbeitung von Testdaten um bis zu 85 %, wodurch weniger Ressourcen benötigt werden. 3️⃣ Compliance und Datenschutz 👉 Bessere Einhaltung von Datenschutzbestimmungen durch den gezielten Einsatz von Daten. 4️⃣ Verbesserung der Test- und Entwicklungsprozesse 👉 Die Nutzung selektiver Testdaten führt zu effizienteren und effektiveren Testverfahren. 👉 Gezieltere Tests ermöglichen es, sich auf die relevantesten Bereiche zu konzentrieren, wodurch die Softwarequalität verbessert wird. Ergo: Die Verwendung selektiver Testdaten verkürzt die Zeit bis zur Markteinführung neuer Produkte und Dienstleistungen – und unterstreicht damit, wie kritisch und vorteilhaft selektive Testdaten für moderne Unternehmen in der Softwareentwicklung sind. Die Entscheidung für selektive Testdaten ist daher nicht nur eine Frage der technischen Effizienz, sondern auch eine strategische Entscheidung. Möchten Sie mehr zu nahtloser Integration und der Übertragung Ihrer Daten wissen und wie Ihnen unsere DataBridge dabei hilft? Dann laden Sie sich unser aktuelles Whitepaper herunter! https://lnkd.in/evxKYXn4 #Datenübertragung #Databridge #dacon

Software schnell mit einem MVP zu validieren, hat sich mehrfach bewährt. Trotzdem solltest du dir vorher bei dieser Sache viel Zeit nehmen: Die Planung deines Datenmodells. Mittlerweile gibt es unzählige Möglichkeiten, um selbst ohne Programmierkenntnisse ein Minimum Viable Product zu entwickeln. Das ist super, denn so kannst du deine Software schneller validieren. Aber dein MVP ohne das Datenmodell zu launchen, das auch deine spätere Endversion stützen soll, wird dir kein aussagekräftiges Ergebnis bringen. Darum lohnt es sich für dich, dir trotz deines schnellen Umsetzungsdrangs genug Zeit zu nehmen, um folgende Fragen zu beantworten: ➡️ Welche Daten sind essentiell für die Funktionen der Lösung? ➡️ Welche festgelegten Dateneigenschaften erleichtern die spätere Nutzung? ➡️ Wie sammelt, verarbeitet und bereitet die Lösung relevante Daten auf? ➡️ Müssen Berechtigungskonzepte mitgedacht werden? Gerade bei komplexen Kundenanforderungen verhinderst du damit, dass später strukturelle Probleme auftreten, die teure und zeitraubende Veränderungen erfordern. Klar, dein Projekt erst mal schlank zu bauen und möglichst schnell zu validieren, ist ein bewährter Ansatz. Aber es bringt dir auch nichts, hastig loszureiten und erst unterwegs festzustellen, dass du das Pferd vergessen hast. Wie stellst du sicher, dass das Datenmodell von Beginn an wirklich zur Lösung passt?

Software kann nicht in der Isolation bleiben. Mit Glasswise biete ich ja selbst Branchensoftware an. Da kann ich es mir genauso wenig erlauben, in der Isolation zu bleiben. Sprich, ich muss Integrationspunkte mit der Außenwelt anbieten. Dafür verfolge ich 2 Strategien: 1) GraphQL + JSON over HTTP API für all jene, die technisch versiert sind und ihre eigene Softwarelösung programmatisch integrieren wollen (oder ich ihre). Später sollen noch Webhooks dazu kommen. 2) Zapier Integration für alle, die technisch nicht so tief hineingehen wollen. Praktisch z.B. um diverse Marketing-Tools anzubinden. Damit ich das Solo stemmen kann, ist es wichtig, auf die richtigen Tools zu setzen. Mit Hasura kann ich APIs in Rekordzeit bauen. Ohne wäre das definitiv nicht machbar. Hasura kann man auch super auf bestehende Datenbankschemas "draufsetzen" und so eine API anbieten. Wie geht ihr das Thema für eure Softwarelösungen an?

Mein lieber Freund David Wippel hat hier mal eine interessante Frage gestellt. Und weil meine Antwort zu lange ist, mach ich einfach mal ein Posting daraus. Seine Frage: https://lnkd.in/ds5Hsmxf Meine Antwort: Das ist eine schwierige Frage. Ich würde mal sagen, das hängt ganz stark vom Projekt und dem Team ab. Da gibt's nicht DIE eine Antwort. Eine Knowledge-Base/Wiki ist nur so gut, wie ihr Inhalt und den zu pflegen ist auch immer ein Aufwand. Ich denke, was schon einmal stark hilft, ist Anforderungen, Umsetzung/Tasks und Kommunikation sauber zu trennen. Anforderungen und Konzeptionsprozesse sollten nicht in JIRA-Tickets oder Tasks abgehandelt oder "dokumentiert" werden. Wenn ich hier direkt zu Beginn des Prozesses ansetze, Anforderungen (die ich ja hoffentlich bereits aufschreibe und nicht zurufe) in einem Wiki, gut strukturiert erfasse, dann ist das schon die halbe Miete. Tickets/Tasks können dann darauf referenzieren (und umgekehrt). Diese Informationen sollen persistiert, permanent gespeichert werden. Beispiele sind hier Notion, jede Art von Wiki, Confluence etc. Die Kommentarfunktionen der Tools können hier übrigens super helfen um auf diese bezogene Dokumentation nachvollziehbar zu machen. Tickets sollten die relevanten Inhalte zusammenführen, aber im besten Fall eben referenzieren. Tickets müssen alle für die Tätigkeit relevanten Informationen beinhalten, aber: Sie sind flüchtig, sie sind irgendwann erledigt und damit auch nicht mehr sichtbar. Task-Management und Kanbans werden von vielen Tools unterstützt (bspw. Notion, Clickup, Monday, JIRA). Noch flüchtiger als Tickets ist Kommunikation. Sie ist für mich der Kleber der hilft die Lücken zu schließen, aber vor allem um sich (Achtung! Sehr flüchtig!) organisatorisch zu koordinieren. Das flüchtigste ist natürlich ein Gespräch oder Telefonat. Ohne Notizen gibt es nur die Erinnerung und die verblasst leicht. Ein wenig besser (weil asynchron) sind Chats, aber auch hier muss man sich bewusst sein: Niemand scrollt 6 Monate Chathistorie durch um eine Information zu finden. Deshalb: 1. Anforderungen gehören in eine Knowledge-Base. Das ist schon die halbe Miete für die Dokumentation. 2. Tasks als das behandeln, was sie sind: Aufgaben (nicht Anforderungen!) 3. Sich niemals auf Kommunikation alleine verlassen. Sie kann die Dinge zusammenhalten, aber sie ist extrem flüchtig.