@nedbat I'm used to JUnit's assertEquals(expected, butgot) and it prints
Expected <<<x>>> but got <<<b>>>
Which is slightly better when you have long chunks of output (HTML and XML), butgot will be at the end instead of buried a page or two up. For short answers it doesn't matter.
#unitTesting #extremeProgramming #soExtreme!
Fascinating, horrifying, and amusing — all at the same time:
"The Sudoku Affair", Zach Tellman (https://explaining.software/archive/the-sudoku-affair/).
On HN: https://news.ycombinator.com/item?id=42953168
On Lobsters: https://lobste.rs/s/khlha3/sudoku_affair
«YAGRI: You are gonna read it» de Scott Antipa.
https://www.scottantipa.com/yagri.html
Su punto de vista va totalmente en contra de la simplicidad que predica Extreme Programming (XP), pero su planteamiento es muy bueno para el mantenimiento. En lugar de quitar columnas en la base de datos dejando lo más elemental y útil, pues... añadir algunas extras que den contexto para una futura depuración: created_at, updated_at, deleted_at, created_by, permissions (usandos), etc. Así resuelves dudas como: ¿cuando se editó por última vez? ¿Por qué se borró y bajo que endpoint? ¿Quién lo creó?
#api #extremeprogramming
Ship Software That Does Nothing
https://kerrick.blog/articles/2025/ship-software-that-does-nothing/
From the Leanpub Podcast archive: Watch author Luca Minudel talk about complexity science and about his experience with Extreme Programming on the Ferrari F1 team: https://youtu.be/Mb9wrBtu7XI?utm_content=bufferd9c3e&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer #books #ebooks #extremeprogramming #complexity
I wish I could travel to Switzerland to attend XP 2025. But maybe you can? https://conf.researchr.org/home/xp-2025 #ExtremeProgramming
Fennoalla on tarkoitus siirtyä vahvemmin kohti autonomisempia ketteriä softatiimejä, eli pääsisit tietynlaiseen murrosvaiheeseen auttamaan tämän homman rakentelussa.
Meikäläisen tavoite on rakentaa XP-ideaaleja seuraava tiimi, eli etenkin sennun kohdalla kaipaan tähän ja lähimaaston aiheisiin mielenkiintoa ja valmiutta.
2/4
The day has arrived! Hope to see many #developers today at #TalentArena2025 where I'll be:
- Sharing a session around #TDD at 10h (Visionary Stage)
- Moderating a panel around #eXtremeProgramming at 17:30h
Sharing is caring 
Say hi if u want to chat 
https://buff.ly/pkoeRIU
Forest and desert, or We Know How To Write Software
https://m.youtube.com/watch?v=nt6m8qtRbz0
I enjoyed this talk by @kentbeck and Beth Andres-Beck (whom I briefly had the pleasure of working with last year). Are you in the forest or the desert?
Added “Extreme Product Development” by Peter Hilton to #awesometalks
https://github.com/JanVanRyswyck/awesome-talks
"That is, in attempting to optimize XP's own practices, they created metrics that, years later, turned out to be excellent tools for measuring and optimizing work."
#softwareengineering #extremeprogramming #dora #metrics
https://drpicox.medium.com/scrum-vs-extreme-programming-was-xp-right-all-along-1bb1061e9e6b
Our Director of Software Development for EWAA, @purinkle, appeared on the A Junior, A Senior and I podcast with Steven R. Baker!
He dives into:
Why eXtreme Programming (XP) is still vital today Its impact on team collaboration and efficiency Tips for integrating XP into your workflow
If you're into agile and sustainable software, this is a must-listen! 
Check it out: https://open.spotify.com/episode/0djMCcFLnAbhEVAwM8VuXO
The other day I read a linked in post by Kent Beck promoting the myth that TDD produces "defect free" code. It's a harmful myth, and I wrote a blog post to explain why.
https://sklivvz.com/posts/tdd-and-the-zero-defects-myth
In 2000, I read about CI/CD, but there weren’t tools yet (CruiseControl came out in 2001). So, we implemented CI by having a physical card that had to be on your desk in order to commit code. Then, you had to go over to our build (desktop) machine, get your code, run the build/test scripts (and fix if you broke them).
We eventually automated it all, but just that step saved a lot of “works on my machine” bugs from breaking our builds.
Just introduced a client to the idea of "management tests", LOL. Everything old is new again!
Shockingly, the link to Josh Kerievsky's original article *is still valid* twenty years later. 
Wow, I expected to have to dig for it.
"Right game, Wrong Team"
by Joshua Kerievsky, 2003
http://www.ddj.com/architect/184414956
#agile #extremeProgramming #testDriven
2200 folks now subscribe to my YouTube channel. Check it out if you want to see how an XPer works in the Apple ecosystem. #XP #ExtremeProgramming #iOSDev #Swift https://www.youtube.com/@QualityCoding
@cosy_skog I've been a professional software engineer since 2001, in the sense that I actually get paid legitimately by large corporations to solve a variety of problems.
The answer is, in my experience, you don't.
All you can really do is trust in your development processes, whichever one you choose to invest time in learning. For me, it was #TestDrivenDevelopment and #ExtremeProgramming.
I often start by creating a crude model of a candidate solution, fully knowing ahead of time that that solution is going to be wrong. But, it starts out as being "good enough" to solve some of the problem at hand. Over time, I just hack on it and refine it, adding tests here and there to verify my understanding and guide my development process. And, yes, there are times, when I go down a wrong path, learn something new about how to do it better, and I end up having to rewrite both tests and production code. It's part of the process. It's frustrating. I often have to walk away from the computer for a day or two to cool off from it. But, it happens, and the end result is usually better for it.
But the process is key -- basically, don't give up, keep chipping away at the problem until you have a solution you are satisfied with, and maybe then move on. Software is rarely ever "done". But, for a given problem, it can be "done enough."
That said, here's a few things I found that works well for me:
Consider designing a solution either from the top-level down or from the inside-out. Never design from the bottom up unless you have sound understanding of the problem domain and customer requirements.
Consider implementing a solution from the bottom-up or from inside-out. Once you have a design (which is really just a "here is how I plan on writing the software components and how they fit together"), it's much easier to lay a working foundation so that you can come to trust in it axiomatically. It's easier to reason about your code if the lower-level foundation has already been proven to your satisfaction.
Try to avoid top-down implementations. These can work (and we have working examples of complex systems written this way, such as the Oberon System and many compilers in the Pascal/Modula family); however, it can also lead to overly complicated implementations. You might find that a lower-level structure doesn't quite fit into the "user interface" (so to speak) of the module you're trying to write, and instead of feeling like you're free to change that interface, you often add adapters or compatibility layers to act as bridges between the high- and the lower-level code. Working bottom up helps eliminate those excess pieces of code.
As you can imagine, working with test-driven development allows you to work "inside-out" which is a valid approach for either situation. You'll often find the quality of the code to sit somewhere in between top-down and bottom-up; some complexities will arise (adapters/shims to facilitate interaction between modules or to support better testing), but it'll not be anywhere near as bad as a purely top-down implementation or a bottom-up design.
Hoping this helps out, and I wish you luck on your learning journey.
️ 
