Projekte. Beratung. Spezialisten. Technische Risiko und Chance für mehr Softwarequalität IKS-Thementag Autor: Dr. Reik Oberrath 25.11.2014 Thementag 25.11.2014, Technische 1 56
Definition 1 Technische Schuld oder Technische (engl. technical debt) ist eine in der Informatik gebräuchliche Metapher für die möglichen Konsequenzen schlechter technischer Umsetzung von Software Der Begriff wird von Informatikern verwendet, um Managern klarzumachen, dass die Hintanstellung von Maßnahmen zur Sicherung technischer Qualität die Softwareentwicklung verlangsamt http://de.wikipedia.org/wiki/technische_schuld Shipping first time code is is like like going into into debt. debt. A little A little debt debt speeds speeds development so long so as long it is paid as it back is paid back Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load Ward Cunningham: The WyCash Portfolio Management System. In: OOPSLA '92 Experience Report. 26. März 1992 Thementag 25.11.2014, Technische 2 56 zahlen? Im größeren Kontext Schlussteil
Auf der Baustelle arbeiten Schick machen Auf der Baustelle arbeiten Refactoring First Time Code Not-Quite-Right Code Clean Code
Altlasten als langfristige Kostentreiber Summe realisierter Feature Mit Refactoring Verlorene Ressourcen Mit Technischen Amortisierungsgrenze Ward Cunningham: A little debt speeds development.. Zeit Ward Cunningham: stand-still under the debt load Nach http://martinfowler.com/bliki/designstaminahypothesis.html
Grundidee Shipping first time code It is paid back Every minute spent on not-quite-right code Stand-still under the debt load Tilgung Zinsen Bankrott 500 Mrd $ * Bildnachweis: http://www.wissen.de/redewendung/ein-klotz-am-bein-sein-2013-05-17 * Vom Marktforschungsunternehmen Gartner geschätzt für aktuellen den globalen IT-Altlastenberg Thementag 25.11.2014, Technische 5 56 ** Vom Wirtschaftsprüfungsunternehmen Deloitte geschätzt für Sourcecode-Fehlersuche in 2012 siehe http://www.datacenter-insider.de/software-on-premise/anwendungen/articles/459751/index3.html
Strategisches Design 1. Niedrige Zinsen nutzen 2. Aktuelle Marktvorteile nutzen Thementag 25.11.2014, Technische 6 56 zahlen? Im größeren Kontext Schlussteil
Grenzen der Metapher freie Softwareentwicklung gibt es nicht Bei wem macht man Technische? Wer ist die Bank? Technische erlöschen nach dem Betrieb der Software Technische werden nicht in vielen kleinen verbindlichen Raten zurückgezahlt Viele Technische entstehen unbewusst, echte aber i.d.r. halbbewusst oder ganz bewusst Thementag 25.11.2014, Technische 7 56 zahlen? Im größeren Kontext Schlussteil
Definition 2 A) Technische Schuld im engeren Sinne ist die Summe aller Defizite einer Software, für die sich die Akteure bewusst (oder wenigstens halbbewusst) entschieden haben. Siehe https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt B) Technische Schuld im weiteren Sinne ist die Summe aller Defizite einer Software, also alles, was dem Clean-Code-Gedanken widerspricht. Siehe http://www.clean-code-developer.de/ http://www.clean-coding-cosmos.de/ Thementag 25.11.2014, Technische 8 56 zahlen? Im größeren Kontext Schlussteil
Einleitung Kategorien von Technischen Best-Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag 25.11.2014, Technische 9 56 zahlen? Im größeren Kontext Schlussteil
Kategorien von Technischen 1. Bewusstseinsarten (Motivation, Einstellung) 2. Strategiesorten (Ziele, Planung) 3. Erscheinungsformen (Aussehen, Vorkommen) 4. Buchhaltungstypen (verwaltung, verantwortliche Rollen) Thementag 25.11.2014, Technische 10 56 zahlen? Im größeren Kontext Schlussteil
Bewusstseinsarten (Motivation, Einstellung) Konsequenzen und Gegenmaßnahmen bewusst? Nein Ja bewusst? Ok, sauber geht anders, aber über eine saubere Lösung machen wir uns jetzt keine Gedanken. Wir müssen jetzt liefern. Ja Nein Wir verzichten auf die saubere Lösung. Die entstehenden Probleme sind bekannt und werden beherrscht. Wir müssen jetzt liefern. Erst im Nachhinein: Was ist das Problem? Ach so, wenn wir das vorher gewusst hätten, hätten wir die Chance gehabt, das sauber zu erledigen. Thementag 25.11.2014, Technische 11 56 Nach http://martinfowler.com/bliki/technicaldebtquadrant.html
Bewusstseinsarten (Motivation, Einstellung) Sorglos Kurzsichtig Umsichtig Weitsichtig Bedacht Bewusst Unachtsam Unbewusst http://martinfowler.com/bliki/technicaldebtquadrant.html Thementag 25.11.2014, Technische 12 56 zahlen? Im größeren Kontext Schlussteil
Kategorien von Technischen 1. Bewusstseinsarten (Motivation, Einstellung) 2. Strategiesorten (Ziele, Planung) 3. Erscheinungsformen (Aussehen, Vorkommen) 4. Buchhaltungstypen (verwaltung, verantwortliche Rollen) Thementag 25.11.2014, Technische 13 56 zahlen? Im größeren Kontext Schlussteil
Strategiesorten (Ziele, Planung) Ein großes Defizit Viele kleine Defizite Strategische Langzeit- Taktische Kurzzeit- Unbewusste Bewusste Nach http://www.construx.com/10x_software_development/technical_debt/ Thementag 25.11.2014, Technische 14 56 zahlen? Im größeren Kontext Schlussteil
Strategiesorten (Ziele, Planung) Langzeit- Kurzzeit- Grobgranular Feingranular Wir realisieren kein Continuous Delivery solange der Kunde mit der Auslieferungsdauer zufrieden ist Solange wir keine größeren Probleme mit der alten Technologie bekommen, stellen wir unsere Komponenten nicht um. Wir testen jetzt noch unregelmäßig und erkennen viele Fehler zu spät. Ab der übernächsten Auslieferung nutzen wir Continuous Integration. Unser Sourcecode-Analysetool (Sonar) meldet über 100 Probleme in unseren Sourcen. Nach der übernächsten Auslieferung müssen die behoben werden. Thementag 25.11.2014, Technische 15 56 zahlen? Im größeren Kontext Schlussteil
Kategorien von Technischen 1. Bewusstseinsarten (Motivation, Einstellung) 2. Strategiesorten (Ziele, Planung) 3. Erscheinungsformen (Aussehen, Vorkommen) 4. Buchhaltungstypen (verwaltung, verantwortliche Rollen) Thementag 25.11.2014, Technische 16 56 zahlen? Im größeren Kontext Schlussteil
Erscheinungsformen (Aussehen, Vorkommen) Organisatorische Prozess-bezogene Persönliche Thementag 25.11.2014, Technische 17 56
Persönliche z. B. mangelnde Motivation der Akteure Neues zu lernen, auszuprobieren und sich an Neues anzupassen Organisatorische z. B. veraltete hierarchische Organisationsstrukturen (Gesetz von Conway) Prozess-bezogenen z. B. Anwendung von veralteten Vorgehensmodellen Mehr Informationen dazu unter http://clean-coding-cosmos.de/techdebts-4 Thementag 25.11.2014, Technische 18 56 zahlen? Im größeren Kontext Schlussteil
Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Werkzeug-bezogene Praktische Test-bezogene Organisatorische Prozess-bezogene Persönliche Thementag 25.11.2014, Technische 19 56
Praktische z. B. nicht aus gemachten Fehlern lernen Werkzeug-bezogene z. B. zu großer Wildwuchs an eingesetzten Werkzeugen Automations-bezogene z. B. keine automatische Testausführung (Continuous Integration) Test-bezogene z. B. unzureichende Testabdeckung der implementierten Funktionalität Thementag 25.11.2014, Technische 20 56 Mehr Informationen dazu unter http://clean-coding-cosmos.de/techdebts-4
Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Werkzeug-bezogene Praktische Organisatorische Test-bezogene Betriebs-bezogene AM-bezogene Kommunikationsschulden Prozess-bezogene Fachseitebezogene Persönliche Thementag 25.11.2014, Technische 21 56
Kommunikationsschulden Unzureichende Kommunikation und Zusammenarbeit zwischen den Akteuren (vor allem zwischen Akteuren verschiedener Phasen im ALM) Application Lifecycle Management Administrator Kundenakzeptanztester Architekt / Entwickler Anforderungsanalyst Domänen- Experte Thementag 25.11.2014, Technische 22 56 zahlen? Im größeren Kontext Schlussteil
Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Werkzeug-bezogene Praktische Organisatorische Persönliche Test-bezogene Betriebs-bezogene AM-bezogene Produkt-bezogene Fachseitebezogene Produktions-bezogene Implementierungsschulden Architekturschulden Kommunikationsschulden Prozess-bezogene Thementag 25.11.2014, Technische 23 56
Produktions-bezogene z. B. mangelnde Analysierbarkeit (Logging, Protokollierung, Monitoring) Architekturschulden z. B. mangelnde Berücksichtigung nicht-funktionaler Qualitätskriterien Implementierungsschulden z. B. Code-Vervielfachungen Mehr Informationen dazu unter http://clean-coding-cosmos.de/techdebts-4 Thementag 25.11.2014, Technische 24 56 zahlen? Im größeren Kontext Schlussteil
Erscheinungsformen (Aussehen, Vorkommen) Automations-bezogene Werkzeug-bezogene Praktische Organisatorische Persönliche Test-bezogene Betriebs-bezogene AM-bezogene Produkt-bezogene Fachseitebezogene Produktions-bezogene Implementierungsschulden Architekturschulden Kommunikationsschulden Prozess-bezogene Hauptverantwortung beim Entwicklungsteam Thementag 25.11.2014, Technische Verteilte Verantwortung 25 56
Kategorien von Technischen 1. Bewusstseinsarten (Motivation, Einstellung) 2. Strategiesorten (Ziele, Planung) 3. Erscheinungsformen (Aussehen, Vorkommen) 4. Buchhaltungstypen (verwaltung, verantwortliche Rollen) Thementag 25.11.2014, Technische 26 56 zahlen? Im größeren Kontext Schlussteil
Buchhaltungstypen (verwaltung) Produkt-bezogene bücher : Liste von TODOs und FIXMEs im SourceCode (Code-Tagging-System) Ergebnisse von Sourcecode-Analysetools (z. B. Sonar) Architekturdokumentation (Beschreibung von Schwächen und Risiken) Prozess-bezogene bücher : Projektdokumentation (Projekt-Handbuch, Retrospektive-Bericht) Dokumentation der ALM-Architektur (Leitfaden für die Unternehmenskultur, Beschreibung der Konzernstruktur) konto: Issue Tracker (Jira, Bugzilla, ) Thementag 25.11.2014, Technische 27 56 zahlen? Im größeren Kontext Schlussteil
Buchhaltungstypen (verantwortliche Rollen) Techn. Projektleiter SW-Architekt Typ 1a: Produkt Entwicklungsteam Produktmanager Typ 1: Projekt Product Owner Typ 2: ALM Hauptverantwortung bei Entwicklungsteam Verteilte Verantwortung Typ 1b: Teamprozesse Rahmenprozesse Projektmanager Entwicklungsteam Scrum-Master Gesamtentwicklungsleiter Produktmanager Projektmanager Scrum-Master Thementag 25.11.2014, Technische 28 56 zahlen? Im größeren Kontext Schlussteil
Einleitung Kategorien von Technischen Best-Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag 25.11.2014, Technische 29 56 zahlen? Im größeren Kontext Schlussteil
Best Practise No. 1 Bekannte Probleme in einem Issue Tracker festhalten! Am besten nach Strategiesorte, Erscheinungsform und Buchhaltungstyp getrennt! Thementag 25.11.2014, Technische 30 56 zahlen? Im größeren Kontext Schlussteil
Best Practises I Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Implementierung 1a Codereviews, Sourcecode- Analysetool (z.b. Sonar) -> Metriken Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien anwenden * http://clean-coding-cosmos.de/die-ccd-regeln Thementag 25.11.2014, Technische 31 56 zahlen? Im größeren Kontext Schlussteil
Best Practises I Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Implementierung 1a Codereviews, Sourcecode- Analysetool (z.b. Sonar) -> Metriken Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien anwenden Architektur 1a Gute Architektur- Dokumentation (arc42) (http://www.arc42.de), ATAM Entworfene Architektur sauber umsetzen, schlechte Architektur ändern (http://aim42.org) * http://clean-coding-cosmos.de/die-ccd-regeln Thementag 25.11.2014, Technische 32 56 zahlen? Im größeren Kontext Schlussteil
Best Practises I Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Implementierung 1a Codereviews, Sourcecode- Analysetool (z.b. Sonar) -> Metriken Analysierte Probleme ausbauen, prophylaktisch: Clean Code Developer Prinzipien anwenden Architektur 1a Gute Architektur- Dokumentation (arc42) (http://www.arc42.de), ATAM Entworfene Architektur sauber umsetzen, schlechte Architektur ändern (http://aim42.org) Persönliche alle Selbstreflexion Motivation fördern (Fortbildungen, Teamstimmung) * http://clean-coding-cosmos.de/die-ccd-regeln Thementag 25.11.2014, Technische 33 56 zahlen? Im größeren Kontext Schlussteil
Best Practises II Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Prozessbezogene, organisatorische und Kommuni- kations- 1b 2 2 Kritische Betrachtung der Organisationsstruktur und des Application Lifecycle Managements (ALM) Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung, Aufgabenverteilungen, ändern Thementag 25.11.2014, Technische 34 56 zahlen? Im größeren Kontext Schlussteil
Best Practises II Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Prozessbezogene, organisatorische und Kommuni- kations- 1b 2 2 Kritische Betrachtung der Organisationsstruktur und des Application Lifecycle Managements (ALM) Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung, Aufgabenverteilungen, ändern Praktische 1b Selbstreflexion, Retrospektive-Meetings Prozesse verbessern, Fortbildung Thementag 25.11.2014, Technische 35 56 zahlen? Im größeren Kontext Schlussteil
Best Practises II Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Prozessbezogene, organisatorische und Kommuni- kations- 1b 2 2 Kritische Betrachtung der Organisationsstruktur und des Application Lifecycle Managements (ALM) Arbeitsabläufe, Kommunikationswege, Teamzusammenstellung, Aufgabenverteilungen, ändern Praktische 1b Selbstreflexion, Retrospektive-Meetings Prozesse verbessern, Fortbildung Werkzeugbezogene 1b oder 2 Welche Tools haben wir, welche werden vermisst, und welche gibt es überhaupt noch? Tools mit Lizenzen bei Bedarf zu Verfügung stellen Thementag 25.11.2014, Technische 36 56 zahlen? Im größeren Kontext Schlussteil
Best Practises III Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Automationsbezogene 1b Ist die Kompilierung, Packetierung, Qualitätssicherung, der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert? Continuous Integration, Continuous Delivery Thementag 25.11.2014, Technische 37 56 zahlen? Im größeren Kontext Schlussteil
Best Practises III Erscheinungsform Buchh.- Typ Analyse Gegenmaßnahme Automationsbezogene 1b Ist die Kompilierung, Packetierung, Qualitätssicherung, der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert? Continuous Integration, Continuous Delivery Test-bezogene 1b Wie sieht die Teststrategie aus? Welche Arten von Tests gibt es? Wie hoch ist die Testabdeckung? Vorgehensweisen wie z.b. TDD und BDD kultivieren, für Automation sorgen Thementag 25.11.2014, Technische 38 56 zahlen? Im größeren Kontext Schlussteil
Best Practises III Automationsbezogene Test-bezogene Betriebs- und Produktionsbezogene Erscheinungsform Buchh.- Typ 1b 1b 2 1a Analyse Ist die Kompilierung, Packetierung, Qualitätssicherung, der Bau des Release Kanditdaten, das Deployment, die Installation automatisiert? Wie sieht die Teststrategie aus? Welche Arten von Tests gibt es? Wie hoch ist die Testabdeckung? Wie gut erfolgt die Inbetrieb-nahme? Wie gut können Fehler in der Produktion analysiert werden? Gegenmaßnahme Continuous Integration, Continuous Delivery Vorgehensweisen wie z.b. TDD und BDD kultivieren, für Automation sorgen DevOps (Kommunikation fördern, gleiche Automationswege nutzen) Thementag 25.11.2014, Technische 39 56 zahlen? Im größeren Kontext Schlussteil
Einleitung Kategorien von Technischen Best-Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag 25.11.2014, Technische 40 56 zahlen? Im größeren Kontext Schlussteil
Tilgen oder zahlen? Ein Qualitätsmodell: = Kostenreduktion Produktivitätsvorteil - Aufwand für Qualitätsinvestitionen oder = - Kostenreduktion Nicht-Sanierungskosten Sanierungskosten entweder so: Nach Qualitätsinvestitionen statt technischer im OBJEKTspektrum Nr. 5 2014 oder so: Thementag 25.11.2014, Technische 41 56 Release 1 Release 2 Release 3 Release 4
Tilgen oder zahlen? Es geht um das Mindset Qualitätsinvestitionen es geht nicht um stundengenaues Schätzen von Aufwänden Meistens reicht es, wenn Kosten und Nutzen mit einer Ordinalskala (gering < normal < hoch < sehr hoch) geschätzt werden In vielen Situationen reichen drei Fragen aus, um die Maßnahmen zu bestimmen: 1. Welche Systemkomponenten werden oft geändert und wie ist deren innere Qualität (i. Q.)? 2. Welche Maßnahmen zur Verbesserung der i. Q. bestehen? 3. Welcher Nutzen steht diesen Investitionen gegenüber? Thementag 25.11.2014, Technische 42 56 zahlen? Im größeren Kontext Schlussteil
Tilgen oder zahlen? berge bestaunen hilft alleine nicht weiter! Deshalb die Empfehlung: 1. Technische bewusst machen und festhalten 2. Entscheiden mit welchen Qualitätsinvestitionen der größte Mehrwert erzielt werden kann und Ressourcen zur Realisierung bereitstellen 3. Umsetzung veranlassen und Ergebnisse von den Verantwortlichen einfordern Thementag 25.11.2014, Technische 43 56 zahlen? Im größeren Kontext Schlussteil
Tilgungspläne Keine Tilgung Legende Zinsen zahlen Neue funktionale Änderungen tilgen Tilgungsplan A + einfaches Regressionstesten Release 1 Release 2 Release 3 Release 4 - Kein funktioneller Fortschritt Tilgungsplan B + kontinuierliche Verbesserung der inneren Qualität - Gefahr als Puffer für funktionale Änderungen zu dienen Thementag 25.11.2014, Technische 44 56 zahlen? Im größeren Kontext Schlussteil
Einleitung Kategorien von Technischen Best-Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag 25.11.2014, Technische 45 56 zahlen? Im größeren Kontext Schlussteil
Zeitdruck Rahmenbedingungen Mangelnde Kommunikation Technische Fehlendes Wissen Technologischer Fortschritt Thementag 25.11.2014, Technische 46 56 zahlen? Im größeren Kontext Schlussteil
Langfristig denken ERROR Thementag 25.11.2014, Technische 47 56
Langfristiges Risiko ignorieren Assure internal quality! Deliver in time! Keep to the budget! Ob Schrott entsteht, ist egal. Hauptsache mein Projekt läuft gut. Projekt-Manager Thementag 25.11.2014, Technische 48 56 zahlen? Im größeren Kontext Schlussteil
Wer ist hier der Boss? Risiko! Langfristig schlecht! Technische? Kurzfristig gut! Chance! Innere Qualität! Time und Budget! Produktmanager Projektmanager Thementag 25.11.2014, Technische 49 56 zahlen? Im größeren Kontext Schlussteil
Usability Sicherheit Funktionalität Performanz Zuverlässigkeit Äußere Qualität Wartbarkeit Deployment Releasemanagement Modifizierbarkeit Testbarkeit Architektur Ressourceneffizienz Technologie Design Architektur Code Technologie Design Code Quelle : http://www.dadalos-d.org/frieden/images/eisberg-modell.jpg Portabilität Kompatibilität Innere Qualität Thementag 25.11.2014, Technische 50 56
Technische kurzfristig zurückzahlen Variante 1 (Sichtbarer Kredit) Variante 2 (Verdeckter Kredit) Thementag 25.11.2014, Technische 51 56 Zeit Release 1 Release 2
Komplexität beherrschen Komplexität in der Software Zitate von Ward Cunningham 1992 Langfristiges Risiko: can be brought to a stand-still under the debt load Effizienz in der Softwareentwicklung Mittelfristige Kosten: not-quite-right code counts as interest Best Practises Technische i.w.s. Zeitgewinn Kurzfristige Chance: A little debt speeds development.. Thementag 25.11.2014, Technische 52 56 zahlen? Im größeren Kontext Schlussteil
Einleitung Kategorien von Technischen Best-Practices im Umgang mit Technischen Tilgen oder Zinsen zahlen? Technische im größeren Kontext Zusammenfassung Thementag 25.11.2014, Technische 53 56 zahlen? Im größeren Kontext Schlussteil
Zusammenfassung Die Metapher Technische ist und bleibt trotz ihrer Grenzen gut Sie ist hilfreich das Problem schlechter technischer Umsetzung zu veranschaulichen und zu kommunizieren Es gibt am Produkt, am Teamprozess und am ALM, für die unterschiedliche Rollen verantwortlich sind Es gibt unbewusste, halbbewusste und bewusste Bewusste können gezielt verwaltet werden Unbewusste und halbbewusste bringen ein unbekanntes oder schwer abschätzbares Risiko mit sich Manche Technische stellen eine große reale Gefahr für Projekte und noch mehr für Produkte dar Thementag 25.11.2014, Technische 54 56 zahlen? Im größeren Kontext Schlussteil
Fazit -Management: bewusst machen und festhalten (Issue Tracker) Mit gezielten Qualitätsinvestitionen risikoreiche abbauen -Prophylaxe: Langfristig denken und vermeiden (nur Notfall-Option) Projektmanager auf messbare innere Qualität verpflichten Doppelt und dreifach prüfen, ob ein möglicher Nutzen mögliche Risiken den verschiedenen Stakeholdern (Produktmanager) wert sind Knowhow der Mitarbeiter und Technologien in der Software nicht zu sehr veralten lassen Thementag 25.11.2014, Technische 55 56 zahlen? Im größeren Kontext Schlussteil
Weiterführende Literatur http://martinfowler.com/bliki/technicaldebtquadrant.html http://www.clean-code-developer.de http://www.clean-coding-cosmos.de http://www.construx.com/10x_software_development/technical_debt/ http://de.slideshare.net/jeffsch/beyond-technical-debt http://martinfowler.com/bliki/designstaminahypothesis.html https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technicaldebt http://www.datacenter-insider.de/software-onpremise/anwendungen/articles/459751/index3.html http://jaxenter.de/artikel/umgang-mit-technischen--166985 http://clean-coding-cosmos.de/techdebts-1 Thementag 25.11.2014, Technische 56 56 zahlen? Im größeren Kontext Schlussteil
Fragen
WWW.IKS-GMBH.COM
Projekte. Beratung. Spezialisten. Thementag 25.11.2014, Technische 59 56