The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,860 other subscribers

Archive for the ‘Technical Debt’ Category

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:

–jeroen

Read the rest of this entry »

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 »

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):

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”.

Read the rest of this entry »

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:

Read the rest of this entry »

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:

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

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:

Read the rest of this entry »

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

–jeroen

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

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.”

[WayBack] – Jeroen Wiert Pluimers – Google+

–jeroen

Posted in Development, Software Development, Technical Debt | Leave a Comment »

The Spilled Juice Analogy for Technical Debt | Disciplined Agile 2.X

Posted by jpluimers on 2018/06/21

Interesting take on Technical Debt: [WayBackThe Spilled Juice Analogy for Technical Debt | Disciplined Agile 2.X

Not just because of the analogy, but also because of this comment by Ramu Iyer:

Conway’s Law states that software (or the structure of an IT system) mimics and is isomorphic to the organizational-social structure around it. In layman’s terms, a poorly designed software system is a vivid indicator of the underlying pattern of team communication, coordination and cooperation in the software team. Oftentimes, strained social and organizational interactions get in the way of smooth software development and operation. This results in social liabilities during intergroup coordination and accumulates “social debt” within or across one or more communities in a (software) organization. Any suboptimal socio-technical decisions also impact the technical debt of a software system in tandem. Digging one’s “way out of the technical debt pit” also requires the proactive mitigation of social debt around a system.

Reference:
D. A. Tamburi, et al. Social debt in software engineering: Insights from the industry. Journal of Internet Services & Applications, 2015.

–jeroen

via: [WayBack] Vivid and better analogy than interest payments.The Spilled Juice Analogy for Technical Debt http://buff.ly/2nax1Ng #technicaldebt – Marjan Venema – Google+

 

Posted in Development, Software Development, Technical Debt | Leave a Comment »