YAGNI is too often a plague infecting otherwise good software design. It's a knee-jerk reaction to "I don't have a clue, so I'll ensure that I don't need to have a clue."

The most popular #testing post I had on twitter was this whiteboard drawing I did at 4am.

The Testing Pyramid isn't about software testing. It's about software design. Pass it on.

Published: Why do Teams think Single-branch Development Does not Work?

Despite research showing that Continuous Integration indirectly leads to better quality and stability, implying the practice of trunk-based development, teams believe this cannot work for them.

thinkinglabs.io/articles/202...

Unpopular opinion: Using a variable named sut for the system under test is a bad idea; it makes tests less readable. Sure, it helps with finding the act part of the test but, IMO, needing that is a sign that you need to invest in your arrange and assert parts to improve the overall test readability.

DRY is often confused as "don't repeat code," which was never the intended meaning.

DRY is about knowledge. Don't repeat knowledge.

You can repeat identical lines of code that don't repeat or leak knowledge.

1/2

Published: Why do Teams not practice Continuous Integration?

Everyone in the IT industry agrees that Continuous Integration is a required practice to realise quality and stability. Yet, few teams have truly implemented Continuous Integration. Why is that?

thinkinglabs.io/articles/202...

I just wanted to say, I’m probably more proud of this Ted talk than just about anything I’ve ever done so I’m gonna be absolutely useless for the next couple of weeks as I promote the shit out of this because I want you to watch it because it matters in the moment we are in youtu.be/dVG8W-0p6vg

Oh, I have another one! Available for pre-order!

"But Jason, pair programming is two developers doing the work of one."

Or is it two developers avoiding the rework of seven?

If your tests only tell you when something breaks, you’re missing the point.

Great tests accelerate learning, guide design, expose bad assumptions, and make change SAFE.

Testing isn’t cleanup. It’s engineering. Shipping without fast feedback? That’s not speed. That’s risk.

Most teams don't have a tech problem. They have a learning problem. Fast feedback, short iterations, real users. That’s how software grows.

Stop polishing code in a vacuum. Ship. Learn. Improve. Repeat.

Then I fell into a nest of real software engineers, working in real teams, and realised I didn't know shit.

There are real limits to what you can learn in your bedroom by yourself, and a very real risk you'll end up believing you're great just because it's working for you.