schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
Waarom jouw niet-geoptimaliseerde automatisering niet de schuld is van de developers 🛑
Maar rommelige code is zelden een gebrek aan talent; het is een bijwerking van organisatorische wrijving en krapte in sprintdeadlines. Kijk daarom niet alleen naar de code, maar ook naar het opleverproces. 👇
The crisis of software development comes from two contradictory rules:
- Up-front thinking is Waterfall; we must only learn by shipping
- There's no time for rework, so everything needs to be done right the first time
Bosses thought #AI could break this contradiction. But synthetic insights and vibe code don't actually enable faster discovery & delivery. They are a (poor) alternative to doing these things AT ALL.
Agiles Arbeiten macht meinen Arbeitsalltag besser. Dafür wurde es nur nicht erfunden.
Das erste agile Prinzip lautet: „Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.“
Das gute Arbeitsumfeld ist ein Nebeneffekt. Ein schöner, aber eben ein Nebeneffekt.
Als ich das hier mal zur Umfrage gestellt hab, sahen viele andersrum.
https://no-bullshit-agile.de/nba29-gedankenexperiment-agiles-manifest.html?mtm_campaign=mastodon
Hi! Ich bin grade auf der Suche nach einem Schülerpraktikum im Bereich Computerspieleentwicklung im Raum Berlin/Potsdam. Das Praktikum ist im Februar. Hat vielleicht jemand von euch Connections?
PS: Da ich unter 18 bin, darf ich selbst noch keine NDA Unterschreiben. Meine Eltern unterschreiben gerne alles, wenns hilft.
Gerne boosten, damit es mehr Leute sehen 😉
Meine Projekte: https://olli-games.itch.io/
#gamedev #godot #godotengine #softwaredevelopment #berlin
🚀 NEW on We ❤️ Open Source 🚀
Dr. Venkat Subramaniam calls AI “accelerated inference,” emphasizing its ability to process data and recognize patterns without assuming those outputs equal intelligence.
In this conversation with Barton George, he connects that distinction to developers, problem-solving, agile, and the changing role of coding. Watch the full episode:
https://allthingsopen.org/articles/ai-accelerated-inference-agile-developers
AI made writing code faster, and software delivery didn't speed up to match. The Theory of Constraints predicted exactly this outcome forty years ago, and it also tells you what to do about it: measure your own end-to-end flow before you name the constraint or buy the tooling.
Test Double's River Lynn Bailey explores what this means for AI-assisted software delivery: https://link.testdouble.com/0a428c
The idea of a "tech industry" has always relied on "computer" being a special kind of medium, akin to alchemy. And if tech demands to be king, AI hype has now elevated LLMs to a king of kings.
But the solipsism has hit a dead end. The only way forward is to recognize that computers are not special.
https://productpicnic.beehiiv.com/p/llms-are-just-normal-technology-but-tech-is-just-a-normal-medium
Day 1 of Rails World is in the books! We had some great pairing sessions yesterday in the Double Up Lab, and we're looking forward to even more today. Our CEO Todd Kaufman even grabbed a photo with Matz!
Stop in to see us in the Sponsor Lounge and feel free to bring us something to work on: a stubborn bug, a legacy system challenge, an AI tooling question, or a resume to review. See you on the show floor!
Today is the last in my series about the INVEST method of writing user stories.
https://www.edyouragilecoach.com/t-is-for-testable/
You should be able to test anything that you do.
#GhostGang #SoftwareDevelopment #business #leadership
🏴☠️ 🐻
„Wer agil ist, muss nicht planen." Den Satz höre ich seit Jahren, oft von Leuten, die agiles Arbeiten verteidigen wollen.
Der wahre Kern daran: Der Plan ist wertlos. Eisenhower hat angeblich gesagt, Pläne seien wertlos, das Planen sei alles.
In der Praxis wird daraus etwas anderes. Kein Plan, und der Termin steht trotzdem. Dann plant jemand anders für dich. Ohne dich.
https://no-bullshit-agile.de/nba17-wer-agil-ist-muss-nicht-planen.html?mtm_campaign=mastodon
Curious how AI fits into your development workflow?
Hard Rails bug you can't shake?
Legacy system you're trying to modernize?
Resume that could use another set of eyes?
Bring it to the Double Up Lab at Rails World next week!
Stop by the Sponsor Lounge for a 30-minute pairing session with a Test Double consultant, matched to what you want to work on. Book a Double Up session here: https://testdouble.com/pairing-railsworld
From EuroBSDCon 2026: "What has (can) the EU Cyber Resilience Act done (do) for you?" by Peter Hansteen - video https://exquisite.tube/w/pZuKtVxhfgGYYayG81SwVa article https://nxdomain.no/~peter/what_hascan_eu_cra_donedo_for_you.html @eurobsdcon #eurobsdcon #freebsd #netbsd #openbsd #cra #cyberresilience #softwareengineering #engineerup #softwaredevelopment #PDE #digitalelements
One of the most expensive phrases in software development:
“Don't touch that. Only Brian understands it.”
That's not expertise.
Expertise is valuable.
Dependency is the problem.
Clear, coherent, well-tested code helps knowledge travel across the team.
The goal isn't making everyone interchangeable.
It's making sure the software doesn't depend on one person's memory to survive.
A team can have:
2-week sprints.
Daily stand-ups.
Retrospectives.
A Scrum board.
…and still take six weeks to make a small change.
That's because process agility and technical agility aren't the same thing.
If the code fights every change, the organization eventually moves at the speed of the codebase.
The teams that deliver consistently don't have fewer specialists.
They have more people willing to help outside their usual comfort zone.
That's what turns a collection of experts into a real development team.
Mythos: „Als PO sollst du während des Sprints nicht mit den Devs sprechen."
Der Gedanke ist nicht böse. Devs sollen in Ruhe arbeiten. Nur verschwindet die Rückfrage dadurch nicht, sie wartet. Aus zwei Minuten werden zwei Wochen, und im Review heißt es: konnten wir nicht fertigstellen, es waren Fragen offen.
Individuen und Interaktionen über Prozesse. Steht im Manifest an Stelle eins.
https://no-bullshit-agile.de/nba41-die-devs-bitte-nicht-ansprechen.html?mtm_campaign=mastodon
Ein PDF verlinkt man nicht. Man schickt es rum, und drei Wochen später hat jeder eine andere Version.
Deshalb steht mein Buch jetzt komplett als Seiten im Netz. 34 Kapitel, jedes mit eigener URL, durchsuchbar, kostenlos, kein Formular, keine Mail-Adresse.
Wenn im nächsten Refinement wieder die Frage kommt, wer eigentlich entscheidet: Kapitel 11 verlinken statt eine Datei anzuhängen.
PDF und EPUB gibt es weiter.
„Mit dem LLM bin ich in der halben Zeit fertig. Warum kommt dann beim Nutzer nichts schneller an?"
100.000 GitHub-Devs vermessen: 17-fach mehr Codezeilen. 2,8-fach mehr Commits. Am Ende 1,3-fach mehr Releases. Der Effekt kollabiert genau da, wo Wirkung anfängt.
Er war nie der Engpass. Das Warten auf Entscheidungen war es.
Was du stattdessen messen solltest: https://no-bullshit-agile.de/llm-beschleunigung-messen.html?mtm_campaign=mastodon
Dritte Woche Überstunden. Im Daily fragt keiner, was gestern lief, nur, welcher Bug zuerst dran ist.
Wir behandeln Mehrarbeit wie Kapazität. Ist sie nicht. Du leihst dir Tempo und zahlst mit Fehlern zurück. Einmal beim Bauen, einmal beim Fixen. Nachhaltiges Tempo ist kein Wellness-Thema, sondern Durchsatz.
Warum ihr mit Überstunden langsamer werdet: https://no-bullshit-agile.de/nba76-nachhaltiges-tempo-agil-und-gesund-ohne-burnout.html?mtm_campaign=mastodon
Good development teams don't think, "My part is done."
They think, "Has the customer problem been solved?"
That's a very different mindset, and it changes how people work together.
Ein Dev fragt nach Zeit fürs Refactoring. Antwort: „Bringt dem Kunden nichts."
Daily, Retro, Rollen. Das ist die Spitze des Eisbergs. Darunter liegen TDD, CI/CD, Refactoring, Pairing. Wer nur oben investiert, bekommt kein agiles Team. Nur eins, das Meetings kann.
Was unter Wasser liegt: https://no-bullshit-agile.de/der-agile-eisberg.html?mtm_campaign=mastodon
Letztens beim Durchschauen des Backlogs: 40 Tickets, alle „Priorität 1". Also ist alles gleich unwichtig.
Priorität fühlt sich nach Steuerung an, ist aber nur ein Wunsch mit Etikett. Sie ignoriert, dass ihr eine Kapazität habt. Ein Ticket hochstufen macht nichts schneller, es macht nur den Plan hübsch.
Es gibt ein besseres Wort. Und es ist nicht „Priorität".
Warum das kippt: https://no-bullshit-agile.de/nba08-prioritaeten-sind-quatsch.html?mtm_campaign=mastodon
In which I argue that the current arguments against #GenAI would be very familiar to the times when the printing press was introduced, and will likely have a similar effect: https://youtu.be/kJf3uF60gQk #video #softwaredevelopment
Kein Board hat eine Spalte "warten auf Entscheidung" obwohl das der längste Wartezustand im System ist.
Wir messen Cycle Time und Lead Time. Die Wochen zwischen "Signal gesehen" und "verbindlich entschieden" messen wir nie.
Ein Team, das alle 2 Wochen liefert, aber im Quartalsgremium auf Priorisierung wartet, ist nicht agil. Nur schnell im falschen Takt.
https://no-bullshit-agile.de/nbak12-decision-latency-unsichtbarer-engpass.html?mtm_campaign=mastodon
"That's not my job."
It's a phrase that quietly slows more software teams than most technical problems.
A developer builds the API but won't look at the UI.
Another updates the UI but won't check the database.
Someone else says testing belongs to QA.