#techdebt
“Vibe coding, where 2 engineers can now create the tech debt of at least 50 engineers.” — I Am Devloper
_____
#Development #Programming #Coding #VibeCoding #AI #TechDebt #WebDev #Frontend #Backend #Quotes
Out with the Old: A Spring Cleaning for Your Code
From tech debt to framework fatigue, here’s how to refresh your stack for the cloud-native era.
https://myfear.substack.com/p/out-with-the-old-a-spring-cleaning-for-your-code
#Java #TechDebt #SpringCleaning
Agile Bible, Verse 5:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Now tell me, when every process, idea, stakeholder, task, OKR, strategy, tool, framework, micromanagement, team structure, and team requirement comes top-down…
What exactly are you doing to ensure every individual has the environment and support to deliver their unique value and impact?
(Spoiler: The value and impact is not equal to your role. Shocking, I know.)
Keeping up with the pace of technology evolution is one thing—harnessing its full potential is another.
That's why this edition of Tech to Know dives into the big questions shaping business strategy:
How do we balance cloud scalability with financial discipline?
What does agentic AI mean for business operations?
Are coding assistants as transformative as they seem?
Read now: https://ter.li/164xwn
Holy crap! I just noticed we're up to 130 unit test suites in @pidgin 3 now! Compare that to the 7 suites we have in Pidgin 2!
This is what we've been talking about when we've been saying that we're making the code easier to maintain. The code has been reworked so that we can actually unit test way more of it and we will continue to add more tests as we move forward!
a nice explanation about how tech debt financially impacts a company https://devico.io/blog/the-true-cost-of-technical-debt-a-financial-analysis?utm_source=chatgpt.com #techdebt #programming
There is No Automatic Reset for Engineering
https://agileotter.blogspot.com/2025/03/there-is-no-automatic-reset-in.html
Why I Read Code, Not Just Docs.
Many ask what books I read to know so much. Truth? I read a lot.
The Key is to read Iterative on usage:
I read & test language updates to stay ahead. I read JavaDocs from methods to understand my tools. I dive into source code to see reality.
Marketing slides, old books, outdated websites, foreign benchmarks, YouTube videos, consultants, or sales pitches, code doesn't tell you everything.
That's how I spot:
Frameworks abusing ThreadLocals, reflection, synchronised. "GraalVM-ready" still needing class loading & build on runtime. Cloud SDK packed with 300+ dependencies. Memory leaks, vulnerabilities & hidden bloat.
[...]
AI won't save us, it'll just continue the trend.
When your code is a few KB, but your dependencies rival AAA game installations. Still believe in fairy tales of secure code?
Gigabytes of code you didn't write. Licences you didn't read. Security flaws you didn't anticipate. Yet, you trust them. Adorable.
Not just Node.js. Gradle caches, AWS libs with 400 sub-dependencies + reflection parties. In control? How cute.
I use plain Java with jlink + jpackage. Minimal. Secure. No bloat.
Fewer deps = fewer surprises. Because I care.
But hey, keep stacking that Jenga tower. Watching it fall will be fun.
Resilience. Reliability. Reusability.
Always wrong investments…
If you think bugs, tech debt & maintenance are “normal,” do the world a favor: resign. You’re part of the problem.
MVP/PoC ≠ Done.
It’s a candle - fragile, short-lived.
Real engineering = the light bulb: robust, lasting.
But devs & managers stop at "it works."
Why? Because real engineering demands more.
More thinking. More iterations. More uncomfortable truths.
Product & Tech - Two worlds, but only one is visible.
Mixing them = slower, costlier, dumber.
Resilient systems don’t break. Reliable systems don’t fail. Reusable systems don’t get rewritten.
Start building like you mean it.
I've been seeing this #TechDebt comic going around. It is funny because of the immense gap between the engineer's POV and the project manager's POV. Many engineers think it is funny because of how obvious the problem is. Why can't the project manager see what is in front of his eyes? But I think it reveals a lot more about most engineer's inability to explain the state of a code base. We should strive to make tools that communicate, as clearly as this comic, the state of a code base.
“Ask for forgiveness, not permission” – The Real Cost of Moving Too Fast
https://www.locked.de/ask-for-forgiveness-not-permission-the-real-cost-of-moving-too-fast/
Can a 1,000-Line iOS Controller Be Tamed? This Legacy Code Rescue Shows How 
https://qualitycoding.org/legacy-code-rescue-thousand-line-view-controller/ #TechDebt
️ 6 Tests to 120: A Legacy Code Transformation Story https://qualitycoding.org/legacy-code-rescue-thousand-line-view-controller/ #TechDebt
"Show don't tell" of federate #FOSS code & apps doesn't work well in environment where we need "Show don't tell" of #OpenStandard specs to make progress. Especially if the specs are so vague that each code implementation thrown in the cauldron of #ActivityPub #fediverse installed base is known to only add #ProtocolDecay and #TechDebt.
In #Commons #CommonSense makes #CommonsSense: Don't introduce the opposite of #interoperabily when in pursuit of seamless interop.
We need both forms of showing.
I have a small #HomeLab which provides #Pihole, recursive #DNS via #unbound, #jellyfin, #nextcloud and ofcourse #backups for a variety of services which I host or manage.
I started #100DaysOfHomeLab on Jan 10 to get rid of all the #techdebt - streamlining scripts, ensuring backups, full disk encryption, getting more services running.
So far I have bought another 2TD HDD and trying to put my current setup into mirror #raid using #ZFS.
Breaking Down the Massive View Controller: A Step-by-Step Rescue Guide https://qualitycoding.org/legacy-code-rescue-thousand-line-view-controller/ #TechDebt
IT is, when you're hiring a master chef 
, but then you are insisting that they only bake the crust 
. Companies hire IT experts but overload them with their business tasks and operational demands, leading to incomplete solutions, growing technical debt, costs and an endless cycle of maintenance, stifling innovation and development. Let's use experts as a service, not as a slave. You order, they build and work as they need. IT can't be structured.
