Today we’re discussing the sunk cost fallacy - what it is, why it matters, and what to do when you find yourself or those around you buying into it.

Have questions or thoughts about what we discussed today? Contact us at podcast@experoinc.com or on Twitter @experoinc

The Sunk Cost Fallacy

In this interview with Coraline Ada Ehmke, Lead Software Engineer at Instructure, we discuss data-driven refactoring and developer happiness teams. Coraline gives some great advice on the kinds of tests we should write for refactoring, tools to use and metrics to monitor, to make sure our refactoring is effective. We also learn about the role of refactoring in the Developer Happiness team at Instructure.

Coraline Ada Ehmke - Refactoring to a Happier Development Team

#080. Complexidade Ciclomática

What counts as code refactoring and what doesn't? Here you'll learn that refactoring is the act of changing software’s structure without changing external behavior. Learn more in this podcast. You can read the article here http://bit.ly/2K6nDa4

What Refactoring Is And Is Not

Martin Fowler chats about the work he’s done over the last couple of years on the rewrite of the original Refactorings book. He discusses how this thought process has changed and how that’s affected the new edition of the book. In addition to discussing Refactors, Martin and Wes discuss his thoughts on evolutionary architecture, team structures, and how the idea of refactors can be applied in larger architecture contexts.

Why listen to this podcast:

 -    Refactoring is the idea of trying to identify the sequence of small steps that allows you to make a big change. That core idea hasn’t changed.
 - Several new refactorings in the book deal with the idea of transforming data structures into other data structures, Combine Functions into Transform for example.
 - Several of the refactorings were removed or not added to the book in favor of adding them to a web edition of the book.
 - A lot of the early refactorings are like cleaning the dirt off the glass of a window. You just need them to be able to see where the hell you are and then you can start looking at the broader ones.
 - Refactorings can be applied broadly to architecture evolution. Two recent posts How to break a Monolith into Microservices, by Zhamak Dehghani,  and How to extract a data-rich service from a monolith by Praful Todkar on MartinFowler.com deal with this specifically.
 - Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example.

More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2QbdHej

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Subscribe: www.youtube.com/infoq
Like InfoQ on Facebook: bit.ly/2jmlyG8
Follow on Twitter: twitter.com/InfoQ
Follow on LinkedIn: www.linkedin.com/company/infoq
Check the landing page on InfoQ: https://bit.ly/2QbdHej

Show Notes

Martin Fowler Discusses New Edition of Refactoring, Along With Thoughts on Evolutionary Architecture

ok so like what if OS systems gained sentience but they had depression and there are religious undertones because why not

Motherboard Take My Tears

When you see the code that needs improvements you, as a good programmer, fix it because you don't want the bad quality to stay in your project. However, this good intent only harms the project. When you work in a team, you are not allowed to do what is not approved by the project. Every time you see an opportunity for refactoring, make a ticket and let the project decide when and who will do it.

The video is here: https://youtu.be/PkmVF64mZNo

M104: Refactoring without a ticket means stealing project resources

Neste primeiro vídeo sobre clean code, fazemos uma breve introdução sobre o assunto, explicando a motivação em se adotar as práticas propostas pelo livro.

Url do livro em Português:
https://www.amazon.com.br/C%C3%B3digo-limpo-Robert-C-Martin/dp/8576082675/ref=sr_1_4?adgrpid=61526443084&gclid=EAIaIQobChMIyt2d5e6V5gIVjIORCh0ECQVtEAAYASAAEgLhtPD_BwE&hvadid=326935150202&hvdev=c&hvlocphy=1001754&hvnetw=g&hvpos=1t1&hvqmt=e&hvrand=1848534005526283565&hvtargid=kwd-300197688610&hydadcr=5621_10696862&keywords=clean+coder&qid=1575251949&sr=8-4

O que é clean code?

Oft schaut man als Entwickler Code von früher an und fällt erst einmal aus allen Wolken: Dort ein Bug, dort schlechte Variablenbenennung, außerdem hat sich der Kunde beschwert, dass da etwas nicht funktioniert. Außerdem ist die Software-Architektur des Projekts nicht so ausgereift.

Dann überlegt man – wenn schon, dann richtig. Wäre es nicht einfach bessser, das Projekt noch mal neu zu starten und mit einem klar strukturierten Architektur anzufangen?

Kurze Antwort: Nein!

Lange Antwort: In jedem Projekt stecken, bis es wirklich funktioniert, tausende kleine Anpassungen. Natürlich gibt es eine optimale Systemarchitektur – quasi ein „Ideal“. Doch dieses Ideal erreicht man nicht, indem man das Projekt von vorn anfängt. Die Kosten dafür sind einfach zu hoch.

Was ist also die Alternative?

Die beste Lösung ist, das Projekt Stück für Stück auf die Zielarchitektur umzubauen. Dazu bedient man sich des Werkzeugkastens des „Refactorings“.

Denn Code hat immer 2 Dimensionen: Eine High-Level- und eine Low-Level-Dimension.

Arbeitet man auf der Low-Level-Dimension sauber, wird das Programm nicht abstürzen und sich in jeder erdenklichen Situation richtig verhalten. Außerdem stimmt dann auch die Performance.

Auf der High-Level-Ebene sind andere Dinge wichtig:
    • Ist die Software auf mehreren Betriebssystemen lauffähig?
    • Lässt sich die Software an neue Kundenbedürfnisse anpassen?
    • Lässt sich die Software auch für andere und ähnliche Anwendungsfälle einsetzen?
    • Lässt sich die Software gut von Menschen bedienen? UI-technisch
    • Lässt sich die Software gut von Maschinen bedienen? Ich rede hier von API-Anbindung und ähnlichem

Einfache Bugs fixt man, indem man 1-2-3 Zeilen im Code abändert. High-Level-Änderungen benötigen oft Code-Anpassungen quer über das gesamte Projekt: Umbenennungen, neue Parameter in Interfaces, neue Aufteilung von Klassen….

Oberstes Ziel eines Refactoring sollte immer sein, so viel wie möglich Code zu entfernen, ohne die Funktion des Programms dabei einzuengen. Das bedeutet in erster Linie: Code Duplication aufspüren und anhand der gefundenen Duplikate verallgemeinern.

Oft ergeben sich durch diese Zusammenführung unterschiedlichster Code-Abschnitte zu Hilfsfunktionen ganz neue Sichtweisen auf das eigene Werk: Plötzlich muss man einen neuen Namen oder Begriff für eine Funktion finden, die zum Beispiel Angebote und Rechnungen gemeinsam haben. Was haben denn Angebote und Rechnungen gemeinsam? Sie besitzen beide eine Nummer aus einem Nummernkreis, sowie eine Liste von Positionen mit jeweils Bezeichnung, Menge und Preis. Doch die Struktur allein gibt uns noch keine guten Ideen für eine Benennung der Funktion.

Wir haben die Funktion am Ende „Vertriebsvorgänge“ genannt. Dazu zählen Angebote, Rechnungen, Lieferscheine, aber auch Einkäufe / Einkaufslisten. Allein die Benennung hat uns einen unheimlichen Schub an Ideen gegeben, was Vertriebsvorgänge eigentlich alles tun können.

Einmal deduplizierter Code ist awesome. Er lässt sich nicht nur an den 2 deduplizierten Stellen verwenden, sondern man findet in der Regel noch zig weitere Anwendungsfälle für allgemeinen Code.

Noch ein Nachtrag: Ich habe vorhin behauptet, High-Level-Code-Anpassungen erstrecken sich über das komplette Projekt. Das mag stimmen für traditionelle Programmiersprachen. Es gibt aber eine neuartige Programmiersprache namens FOP, bei der ist das etwas anders – zumindest für bestimmte Fälle. Bei der FOP-Programmiersprache kann man zum Beispiel in einem einfachen 5-Zeiler dafür sorgen, dass jede Funktion, in der PDFs generiert werden, eine Kopie des PDFs in einem Dokumentenmanagement ablegen. Wie genau diese Sprache solche abstrakten Anpassungen lokal halten kann, erfahrt ihr, wenn ihr den Podcast abonniert.

Folge 7: Code neu schreiben, Projekte weiterpflegen

Bei der Softwareentwicklung gibt es ein magisches Dreieck: Der Kunde will gleichzeitig Hohe Qualität, niedriges Budget, schnelle Fertigstellung. Es gibt ein geflügeltes Wort: Hohe Qualität, niedriges Budget, schnelle Fertigstellung - Das sind die 3 Eigenschaften, die du willst. Suche dir 2 davon aus.
Bei technologischen Schulden entschied man sich für niedriges Budget und schnelle Fertigstellung unter Aufopferung der Qualität. Faktoren, die führen zu technischer Schuld führen können, sind:
    • Unwissenheit 
    • Faulheit 
    • Zeitdruck 
    • Geldmangel
    • die bewusste Entscheidung, unreife Prototypen zu produzieren, um sie zu testen  
Technische Schulden drücken sich insbesondere durch schlecht strukturierte IT-Lösungen aus. Daraus folgen:
    • Sicherheitslücken 
    • Nach Updates funktionieren einige Dinge nicht mehr 
    • Neue Funktionen hinzuzufügen wird sehr teuer/aufwendig 
Technische Schulden muss man abbauen – aber nicht immer.
Denn der Grund, warum man Technische Schulden überhaupt macht ist, dass das Projekt schneller voran geht. Oft weiß man nicht, ob der Kunde ein Feature später behalten oder wieder wegwerfen will. Auch will man die Zeit nicht direkt investiren, alles „ordentlich“ zu machen, da man noch genügend andere Sachen zu tun hat.
Technologische Schulden fordern Zinsen, aber auch Zinseszinsen. Und genau um die Zinseszinsen soll es gehen: Ist eine Software oder ein IT-Projekt schlecht strukturiert, kann man den Fehler am Anfang noch einfach beheben. Je mehr darauf aufbaut, desto schwieriger wird es aber, die Fehler aus der Vergangenheit zu korrigieren.
So entstehen zum Beispiel auf den Provisorien weitere Übergangslösungen und Hacks, die die Komplexität des IT-Projekts unheimlich in die Höhe treiben.
Zu dem ursprünglichen Ziel, Zeit zu sparen und schnell nutzbare Ergebnisse haben, kommen nicht nur die Kosten des “Aufräumens” hinzu, sondern es werden komplett neue Systeme um das schlecht Strukturierte System herum gebaut, die im Falle einer Korrektur wieder obsolet werden – sprich: Verlust durch Abschreibung.
Für den Entwickler können wir folgende Faustregel mitgeben:
Bevor man ein System um eine Funktion erweitert, wird das System geprüft, ob es für diese neue Funktion geeignet ist oder umstrukturiert werden sollte.
Das ist zwar etwas mehr Arbeit, während der Kunde auf die schnelle Umsetzung seines Features wartet. Es lohnt sich aber: Der Implementierungsaufwand für die neue Funktion sinkt drastisch, wenn das darunterliegende System besser geeignet ist. Veranschaulicht heißt das:
Bevor man neue technologische Schulden aufnimmt, muss man die alten Kredite abbezahlen
Damit man Herr über seine Schulden bleibt, sollte man diese in einer Art „technischem Schuldenbuch“ dokumentieren. Dazu eignen sich prinzipiell zwei Techniken:
In der ersten Technik schreibst du alles, was du noch nicht implementieren willst, als Kommentar in den Code: Ausgelassene Sicherheitsprüfungen mit /* TODO: sanitizen */ - an eine Klasse konkrete Infos: TODO: Diese Klasse mit Klasse Y zu gemeinsamer Klasse Z zusammenführen.
In der zweiten Technik nutzt du dein Issue-Tracking-System, um die TODOs zu organisieren.
Wenn du ganz schlau bist, kombinierst du beide Techniken: Im Code machst du einen Kommentar TODO: #1337: Refactorn und unter der 1337 hinterlegst du dann genaue Beschreibungen, was du dort genau weggelassen hast.
Wenn dich diese Sachen weitergebracht haben, dann abonniere diesen Podcast.

Folge 10 - Technische Schulden

Interviews with makers about how they build great software

Software engineers, architects and team leads have found inspiration to drive change and innovation in their team by listening to the weekly InfoQ Podcast. They have received essential information that helped them validate their software development map. We have achieved that by interviewing some of the top CTOs, engineers and technology directors from companies like Uber, Netflix and more. Over 1,200,000 downloads in the last 3 years.

just a ghost using this place to put up tracks or anything I stop working on.

Join Expero's team of tech experts as they discuss best practices and lessons learned from the battlefield of consulting. Hosts and guests draw from a deep well of experience working with custom software products, supply chain optimization systems, biotech manufacturing workflows, financial service modernization efforts, and everything in between.

Software developer at Huawei, founder of Zerocracy, author of Elegant Objects, creator of Zold

Popular tracks tagged #refactoring