Some of the video URLs of #kotlinconf23 most via [Wayback/Archive] KotlinConf’23 – YouTube:
Archive for the ‘Technical Debt’ Category
KotlinConf’23 video streams (including the keynote by Kevlin Henney which is generic to any programming language or concept)
Posted by jpluimers on 2026/05/26
Posted in ChatGPT, Code Quality, Conference Topics, Conferences, Development, Event, Java Platform, Kotlin, Pingback, Software Development, Stackoverflow, Technical Debt, Testing | Leave a Comment »
Having some Technical Debt is OK as long as you keep paying the debt: Refactoring Is Not Just Clickbait – Kevlin Henney – NDC Oslo 2022 – YouTube
Posted by jpluimers on 2025/10/28
[Wayback/Archive] Refactoring Is Not Just Clickbait – Kevlin Henney – NDC Oslo 2022 – YouTube
Via:
- [Wayback/Archive] Arda Cetinkaya on Twitter: “If you are doing some new business as MVP, focusing on business quality rather than technology quality is more important. It’s ok to have some tech. debts that can be paid later. It’s OK if no good answer for “How?” but it’s not OK to not have a solid answer for “What?” 🧑🏽💻”
- [Wayback/Archive] Alican Korkmaz on Twitter: “@ArdaCetinkaya Agreed. In this video, @KevlinHenney explains that having tech debt should not be perceived as dreaded as it is. The important thing is regularly visiting and paying them.”
–jeroen
Share this:
Posted in Agile, Code Quality, Conference Topics, Conferences, Development, Event, Refactoring, Software Development, Technical Debt | Leave a Comment »
From @forrestbrazeal: Boilerplate code through ChatGPT or Google slows development teams down similar to technical debt
Posted by jpluimers on 2025/07/30
Via [Wayback/Archive] Angie Jones on Twitter: “Chart by Forrest Brazeal” I found the original at [Wayback/Archive] Forrest Brazeal on Twitter: “Just saying. “ Read the rest of this entry »
Share this:
Posted in AI and ML; Artificial Intelligence & Machine Learning, Conference Topics, Conferences, Development, Event, Software Development, Technical Debt | Leave a Comment »
Every conversation about dependencies since 2020 uses the same XKCD 2347 based image, which is a problem on multiple levels
Posted by jpluimers on 2024/08/01
The below picture is a modification of [Wayback/Archive] 2347: Dependency – explain xkcd
Title text: Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.
It actually emphasises the problem both that [Wayback/Archive] xkcd 2347: Dependency is way too optimistic, and that everyone uses that to point out dependency issues or worse as a thought-terminating cliché .
The second problem amplifies itself by increasing the popularity of the comic, and the attracts people to use it even if they hardly know about dependencies.
In turn it diminishes the meaning of it, kind of making it more optimistic by basically amplifying the message “there is just one really fragile project our design/infrastructure depends on” (the infamous “A project some random person in Nebraska has been thanklessly maintaining since 2003”).
The sad reality is that this single fragile project is just not true. Modern development and infrastructure systems usually are underpinned by package managers installing the complex graphs of dependencies of which dozens, heck thousands are maintained for “free” by, more often than not, a single worn out maintainer per dependency.
It’s just that over the last few decades usually only one such package at a time posed a serious problem. But with dependencies on very small building blocks, the amount of blocks is rising as is their usage. Just two examples out of the Node JS world (mind you, each development and infrastructure stack lives in comparable worlds):
- [Wayback/Archive] NPM – “is-even”, 160k weekly downloads | Hacker News
- [Wayback/Archive] Expert grabs expired domain for NPM package to make a point • The Register
Mind you, these links are 2021 and 2022, so the numbers have increased.
Many think such problems are limited to programming errors, but over the last decade these have become the tip of the iceberg. The real problems now are that maintainers are fading away as they have for instance been worn out for too long, or simply are aging. So what we have seen over the last decade is the rise of supply chain attacks.
One such example was the XZ utils backdoor which was, by sheer luck because one guy tried to investigate why connecting over ssh had become much slower than before, barely detected in time. It had a CVSS score of 10.0, the highest possible score.
So be prepared that the below picture will have “your business structure” on the top, and towards the bottom a bunch of small fragile pillars with the text “many projects, each maintained by a worn out person on the verge of collapse”.
Share this:
Posted in Awareness, Conference Topics, Conferences, Design Patterns, Development, Event, Fun, Software Development, Systems Architecture, Technical Debt, xkcd | Leave a Comment »
Avoid a software rewrite: it usually brings more trouble and puts you at a distance to competitors
Posted by jpluimers on 2023/11/22
[Wayback/Archive] lisacrispin on Twitter: “👇 This. If you want a new architecture, use the strangler fig pattern, and as he says in the thread, do it in prod. If you spend all your time rewriting, and your competitors spend that time adding new features for customers, your product will be in trouble.” / Twitter pointed me to the below thread.
The urge of rewrite often comes from a feeling of too much technical debt to carry. Preventing that technical debt in the first place would make this feeling go away in the first place so please strive for bringing down and limiting technical debt in the first place.
More about the above tweet further on in this blog post, but now back to the “rewrite everything” pit many fall into.
I saved the whole thread in [Wayback/Archive] Thread by @andrestaltz on Thread Reader App – Thread Reader App of which this are a few highlights:
Share this:
Posted in Agile, Code Quality, Design Patterns, Development, Software Development, Systems Architecture, Technical Debt | Leave a Comment »
Don’t fall for the golden hammer: avoid git empty commits, especially for kicking off parts of your CI/CD
Posted by jpluimers on 2022/08/16
A while back Kristian Köhntopp (isotopp) wrote a blog post after quite a Twitter argument where he poses against using git empty commits. I’m with Kris: don’t use them for anything, especially not for kicking off your CI/CD.
Basically his blog post is all about avoiding to think you have a golden hammer, and avoid falling for the Law of the instrument – Wikipedia.
Originally, Abraham Maslow said in 1966:
“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
For me this has all to do with preventing technical debt: find the right tool to kick your CI/CD pipeline after part of that chain somehow malfunctioned is way better than polluting the commit history with empty commits.
His blog post: [Wayback/Archive.is] Empty commits and other wrong tools for the job | Die wunderbare Welt von Isotopp
The most important bit in it:
And since we are talking about CI/CD pipelines: Don’t YAML them. Don’t JSON them. Don’t XML them.
…
Programming in any of these three is wrong use of tooling, and you should not do it.
- YAML, JSON and XML are for declarative things.
- Python, Go and Rust are for procedural things.
- Bash is for interactive use only.
Use the proper tooling for the job. Be an engineer.
This very much reminds me of an Entwickler Konferenz keynote a long time ago, where Neal Ford made the point that most software engineers act very much unlike what is expected from traditional engineering way of operating where the engineer is both responsible and liable for his actions.
The start of the Twitter thread: [Archive.is] Kristian Köhntopp on Twitter: “A lot of people right now that git is an API and triggering CI/CD pipelines with empty commits replaces the equivalent of a Kubernetes controller for their fragile pile of bash in git triggers. This is broken and begets more brokenness. Evidence:… “
The tweet that started the subtweet: [Archive.is] Florian Haas on Twitter: “(For anyone wondering, what’s nice about this one is it works in any CI. So you don’t have to remember how to manually kick off a GitLab CI pipeline or GitHub Action or Zuul job, you just push an empty commit and off you go.)”
Other relevant tweets:
- [Archive.is] Kristian Köhntopp on Twitter: “If you go down this path, stop right now and rethink your life choices. If you ever need this, you are very likely holding it very wrong and you need to wake up the engineer in you.”
- [Archive.is] Patrick Gerken on Twitter: “Naja, sowohl bei git als auch bei der gitlab api muss ich mich einmal authentifizieren und die auth daten irgendwo sicher ablegen. Dann ist es bei beidem ein einzelnes Kommando. Ich bin nur auf der Console in der Regel noch nicht bei der APIauthentifiziert.… “
- [Archive.is] Patrick Gerken on Twitter: “… “
- [Wayback/Archive.is] How to trigger pipeline securely from the terminal ($2185598) · Snippets · Snippets · GitLab
This solution still has one drawback. Gitlab requires a project specific token. If every developer uses the same token, its validity is bound to the project and not the individual contributor. While Gitlab allows users to create personal access tokens, you cannot require such a token to trigger a pipeline.
- [Wayback/Archive.is] How to trigger pipeline securely from the terminal ($2185598) · Snippets · Snippets · GitLab
- [Archive.is] Patrick Gerken on Twitter: “… “
- [Archive.is] Kristian Köhntopp on Twitter: “”But I need to retrigger the deployment, because I need a Terraform run after I lost an instance.” This needs a proper reconciliation loop. If you are not on K8s, you need to write a thing that reinvents K8s for your infrastructure.”
- [Archive.is] Kristian Köhntopp on Twitter: “Normale CI-Pipelines haben eine REST-API, die man curlen kann, wenn man sich 15 Sekunden Zeit nimmt, die Doku zu greppen.… “
- [Archive.is] Kristian Köhntopp on Twitter: “Take this instead.… “ / [Archive.is] Kristian Köhntopp on Twitter: “Empty commits and other wrong tools for the job If you look at empty commits and think they can be useful for you, maybe you need to stop and think.”
- [Archive.is] Jeroen Wiert Pluimers on Twitter: “That “Be an engineer” is very much no coincidence and reminds me of an @EntwicklerKON keynote by @neal4d a long time ago where he posed that IT engineers act very much unlike traditional engineers and hardly bear responsibility or liability. So use the right tool for the job.… “
Yes, you want to avoid shell too (anything like for instance sh, ash, dash, bash or zsh), but you have to know it (and understand why to avoid it) as often it is the only interactive way to access systems from the console.
And of course Kris also wrote a big document on that too, which is available as full PDF (Wayback), full HTML (Wayback) and chaptered HTML Die UNIX Shell /bin/sh.
But more importantly, Kris wrote [Wayback/Archive.is] Using Python to bash | Die wunderbare Welt von Isotopp which is about using Python to do things you might be tempted to do in the shell. It quotes
Shell is a thing you want to understand and then not use, because you learned to understand it.
which is from the German post in thread [Wayback/Archive.is] Bashprogrammierung, wo gehts am besten los which quotes Kris’ 1998 message:
From kris Tue Sep 1 11:26:12 1998 From: kris Newsgroups: de.comp.os.unix.misc Subject: Re: Shell-Frage, find, xargs, kopieren von vielen Dateien References: <6seh24$q9a$2...@nz12.rz.uni-karlsruhe.de> From: kr...@koehntopp.de (Kristian Koehntopp) Alignment: chaotic/neutral X-Copyright: (C) Copyright 1987-1998 Kristian Koehntopp -- All rights reserved. MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Marc.Hab...@gmx.de (Marc Haber) writes: >mir ist das ganze Zeug mit der Shell, find, xargs und Konsorten noch >reichlich verschlüsselt. http://www.koehntopp.de/kris/artikel/unix/shellprogrammierung/ >xargs hin oder sollte ich besser ein Perlskript schreiben? Verwende Perl. Shell will man koennen, dann aber nicht verwenden. Kristian
–jeroen
Share this:
Posted in *nix, *nix-tools, ash/dash, ash/dash development, bash, bash, Conference Topics, Conferences, Continuous Integration, Development, DVCS - Distributed Version Control, Event, git, Power User, Scripting, sh, Sh Shell, Software Development, Source Code Management, Technical Debt | Leave a Comment »
Powershell code formatting and coding style and style guides: some links and elaboration
Posted by jpluimers on 2022/07/05
I started doing occasional PowerShell “work” long before Visual Studio Code came along with its [Wayback] PowerShell Extension.
Back then, my tool of choice was PowerGUI: Settling on PowerGUI for PowerShell development. Before that it was PowerShell ISE.
Since then, I fiddled around a bit with Visual Studio Code, but not much. Then I got treated for rectum cancer, and when writing this, I’m back to Visual Studio code with the PowerShell Extension and already figured out a lot has improved.
One of the things is code formatting. Back some 7 years ago, this was all not set in stone. Now it is, so it is important to adhere to.
I already posted Code Layout and Formatting: Indentation · PowerShell Practice and Style last year, so now it is good repeat the link in it and add some more.
For my link archive:
Share this:
Posted in Development, PowerShell, Scripting, Software Development, Technical Debt | Leave a Comment »
Attacking Technical Debt – ardalis
Posted by jpluimers on 2021/08/12
Interesting approach in [WayBack] Attacking Technical Debt – ardalis.
The tech stuff is C# and .NET based, but the general approach can be applied in a universal way.
via: [WayBack] Jim Holmes on Twitter “Great post by @ardalis on attacking Technical Debt. … You should also read my series on creating a Technical Debt Payment Plan, starting here: …”
So also read
- [WayBack] Guidepost Systems – Creating a Technical Debt Payment Plan – Should We Fix It?
- [WayBack] Make a technical debt payment plan – Trish Khoo
–jeroen
Share this:
Posted in .NET, C#, Development, Software Development, Technical Debt | Leave a Comment »
Tech Debt by MonkeyUser
Posted by jpluimers on 2019/11/07
[WayBack] Tech Debt (by MonkeyUser: Software development satire) is one of the best images on Tech Debt I ever encoutered (via[WayBack] Tech Debt by @ismonkeyuser https://www.monkeyuser.com/2018/tech-debt – ThisIsWhyICode – Google+):
–jeroen
Share this:
Posted in Agile, Conference Topics, Conferences, Development, Event, Software Development, Technical Debt | Leave a Comment »
Technical debt: “taking shortcuts leads to long-term bleeding…”
Posted by jpluimers on 2019/07/19
From a while ago:
Just tried to explain technical debt: “taking shortcuts leads to long-term bleeding.”
–jeroen
Share this:
Posted in Development, Software Development, Technical Debt | Leave a Comment »
The Wiert Corner - irregular stream of stuff 