Beitrag von Florian Huonder

🚨 Die Risiken und Warnsignale bei der Übernahme und Weiterentwicklung eines bestehenden Softwareprodukts von einem anderen Dienstleister. Bei der okto GmbH haben wir bereits Erfahrung mit der Übernahme und Weiterentwicklung von Softwareprodukten unserer Kunden gesammelt. Doch jede Übernahme birgt ihre eigenen Risiken und Herausforderungen. Einige Warnsignale in Bezug auf die Code-Qualität: ⚠ Fehlende oder unzureichende Dokumentation ⚠ Mangel an automatisierten Tests ⚠ Veraltete Software-Bibliotheken ⚠ Einsatz von unterschiedlichen Programmiersprachen ⚠ Mangelhaftes Software-Design Anfangs sieht meist alles ziemlich in Ordnung aus. Doch der Teufel steckt oft im Detail. Besser sich ausreichend Zeit nehmen und genau hinschauen, um später mögliche Konsequenzen zu vermeiden. Die Code-Qualität ist zwar ein wichtiger Aspekt, aber nicht der einzige, der bei einer Übernahme berücksichtigt werden sollte. Ein wichtiger Punkt ist (unter vielen anderen) der Grund der Trennung vom alten Software-Dienstleister. -- 🤔 Wie happy bist du mit deinem aktuellen Software-Dienstleister? 🔍 Welche Punkte findest du besonders wichtig bei der Übernahme und Weiterentwicklung von Software? #takeover #software #warnsignale #code #qualität #risiko

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!

Je mehr ich anderen davon erzähle, dass ich gerade meine erste eigene Webanwendung (für mich selbst, nicht als SaaS Geschäftsmodell) komplett neu baue, desto häufiger bekomme ich die Rückfrage: "Warum?" Warum sollte man überlegen, eine Webanwendung selbst zu bauen, wenn es doch für nahezu alle Anwendungsbereiche bereits eine Lösung gibt? Die Antwort ist komplex, und doch recht einfach: Als Anwender nutze ich / nutzen wir i.d.R. Standardsoftware, also ein Set an Funktionen, das für eine große Gruppe von Anwendern gemacht wurde. Damit sind wir nicht nur darauf angewiesen, uns auf die Produktentscheidungen der Softwareanbieter zu verlassen - wir vergeben auch die Chance, uns durch die genutzte Software einen Vorsprung im Wettbewerb zu verschaffen. In meinem aktuellen Newsletter (erfordert eine kostenlose Anmeldung) gehe ich im Detail auf dieses Thema ein, zeige Beispiele und gebe Lösungswege zur Individuallösung (NoCode und Solopreneur-geeignet). 👉

Qualität kostet eben – oder 🫰? Jein! Gerade wenn es um Software geht, die langfristig im Unternehmen eingesetzt wird, sollte nicht nur der Anfangsinvest geprüft werden, sondern auch die mittel- und langfristigen Kosten. Denn ja, zu Beginn eines Projektes ist eine saubere und nachhaltige Softwareentwicklung nach den Clean Code Prinzipien aufwendiger und auch teurer. Hohe innere Softwarequalität sicherzustellen, dauert anfangs länger, als wenn der Quellcode einfach drauf los geschrieben wird. Aber: Eine Software, die: 📍 über Jahre und Jahrzehnte im Einsatz ist 📍 ständig erweitert wird 📍dauerhaft funktionieren muss 📍nachvollziehbar bleiben soll wird ohne eine hohe innere Softwarequalität sehr schnell technische Schulden aufweisen. Und dann wird es richtig teuer 😖 💸. Die vermeintliche Ersparnis zu Beginn ist somit weg und wird mehrfach draufgelegt. ▶️ Was sind eure Erfahrungen mit technischen Schulden? Hätten sie vermieden werden können? #CleanCodeDevelopment #CleanCode #technischeSchulden

📢 Unser CEO Patrick hat einen wichtigen Rat für Deine Software-Projekte! In über 24 Jahren Softwareentwicklung haben wir bei soxes AG eins gelernt: Wenn Du genau weisst, was Du willst, können wir Dir eine passgenaue Software liefern. 𝐉𝐞 𝐤𝐥𝐚𝐫𝐞𝐫 𝐃𝐞𝐢𝐧𝐞 𝐕𝐢𝐬𝐢𝐨𝐧, 𝐝𝐞𝐬𝐭𝐨 𝐛𝐞𝐬𝐬𝐞𝐫 𝐤ö𝐧𝐧𝐞𝐧 𝐰𝐢𝐫 𝐃𝐞𝐢𝐧𝐞 𝐖ü𝐧𝐬𝐜𝐡𝐞 𝐮𝐦𝐬𝐞𝐭𝐳𝐞𝐧. Der Schlüssel bei individueller Software? 𝐃𝐞𝐢𝐧𝐞 𝐙𝐢𝐞𝐥𝐞 𝐦ü𝐬𝐬𝐞𝐧 𝐟𝐞𝐬𝐭𝐬𝐭𝐞𝐡𝐞𝐧. Wenn sie es noch nicht sind, helfen wir Dir dabei, sie zu definieren und in eine massgeschneiderte Lösung zu verwandeln, die genau das macht, was Du Dir wünschst – und vielleicht noch mehr. 💪✨ #Softwareentwicklung #IndividuelleSoftware #Vision #Innovation #Erfolg #soxes

CHECK YOUR IT 💪🏽 Du willst die Effizienz eurer Softwareentwicklung auf die Probe stellen? Dafür haben wir auf Basis der ,,12 goldenen Regeln der Softwareentwicklung‘‘ einen Online-Test entwickelt. Finde in 5 Minuten heraus, welche Potenziale du verschenkst und wo ihr im Unternehmen Millionen verbrennt. Neugierig? 🤩 ➡️ Dann folge dem Link in den Kommentaren ❤️ #Softwarentwicklung #ITEffizienz

Ich habe was zu "Strategien zum Umgang mit Softwaremodernisierung" geschrieben. #Legacy-Software ist meistens schlecht strukturiert. Der Umgang mit ihr ist dementsprechend schwierig. Aber Legacy-Software hat auch Vorteile. Sie zu kennen und auszunutzen, ist zentral, um Legacy erfolgreich zu sanieren. https://lnkd.in/eAVkU9Fh #SoftwareArchitektur #SoftwareModernisierung

Warum? Weil jeder gefundene Fehler alle Beteiligten die Möglichkeit gibt, die in Arbeit befindliche Software zu verbessern und ihre Qualität zu steigern. Software verhält sich in jedem Umfeld anders und selbst wenn wir während der Entwicklung schon viele Tests durchführen, muss die Software am Ende das leisten, was der User von ihr erwartet. Daher ist es immer ratsam, den Endnutzer bereits früh zu involvieren und ihn die Software testen zu lassen. Selbst wenn das bedeutet, dass er Fehler findet und meldet, die bereits bekannt sind. Ja, es kann frustrierend sein, bekannte Fehler zu finden, aber es ist ein wichtiger Teil des Prozesses, der uns letztendlich hilft, eine robuste und zuverlässige Software zu entwickeln. Andernfalls läuft das Projekt Gefahr sich zu verzögern, weil Fehler zu spät erkannt werden, bereits weitere Feature auf fehlerhaften Komponenten aufsetzen oder Teilbereiche komplett neu aufgerollt werden müssen. Wie seht ihr das? Testet ihr gerne oder findet ihr, das ist ein sehr lästiges To-Do? #softwareentwicklung #individuellesoftware #softwaretest #testen #kmu #mittelstand #sigitaleprodukte

Der richtige Umgang mit technischen Schulden will gelernt sein. Neben den Empfehlungen von DevBoost finde ich es noch wichtig, technische Schulden zu quantifizieren. Oft werden technische Schulden erst sichtbar, wenn über längere Zeit der Schaden von technischen Schulden mit Zahlen belegt werden kann. Einige Beispiele, um den Einfluss von technischen Schulden zu quantifizieren, sind: * Werte aus der (hoffentlich vorhandenen) Testautomatisierung erheben, wie z.B. der Grad der Testabdeckung * Komplexitätswerte wie zyklomatische Komplexität berechnen * Regelmäßig Zahlen aus Tools wie SonarQube erheben, wie z.B. Anteil der Codeduplikation * Metriken erheben, die indirekt auf technische Schulden hinweisen, wie z.B. * Velocity des Teams * Performance der Software * Häufigkeit von Bugs Komplexe Herausforderungen erfordern nicht immer komplexe Herangehensweise - oft reicht es, mit einfachen Ideen den ersten Schritt zu tun!

Wer ohne technische Schuld ist, der werfe den ersten Stein. Für alle anderen haben wir 8 konkrete Tipps zum richtigen Umgang damit. In der Produktentwicklung müsst ihr als Softwarehersteller immer wieder die Balance zwischen 👉🏼 Entwicklung neuer Features und notwendigen Aufgaben in Bezug auf Wartbarkeit und Stabilität finden 👈🏼. Seien es regelmäßige Refactorings, das Einplanen von „Aufräumarbeiten“ oder auch die konsequente Dokumentation des Systems. Unserer Erfahrung nach sind aufgebaute Altlasten für viele Entwicklungsteams tatsächlich das größte Bottleneck, um wieder schnell und zuverlässig neue Features liefern zu können. Ein dauerhaftes Ignorieren technischer Schulden birgt Risiken für jeden Softwarehersteller: mangelnde Skalierbarkeit, langsamer Entwicklungszyklen sowie demotivierte Teams. Technische Schulden machen überbordende Refactoring- oder Rewrite-Initiativen erforderlich oder führen im schlimmsten Fall in die „technische Insolvenz“. Damit es gar nicht erst so weit kommt, haben wir Dir konkrete Tipps zum Umgang mit technischen Schulden hier im Blogartikel zusammengefasst: https://bit.ly/3U2Yu2V   #TechnischeSchulden #Refactoring #Softwarehersteller