TDD

Five Underplayed Premises Of TDD | Video

This entry is part [part not set] of 9 in the series Underplayed Premises

Five Underplayed Premises Of Test-Driven Development (Transcript) Hey, it’s GeePaw! I’m here to tell you today about five underplayed premises of Test-Driven Development. These premises form the kind of fundament under which almost all TDD proceeds. And when I say that I’m a TDDer, I almost always mean I am operating inside the little ring formed by these five test-driven development premises. Let’s check them out. We’re In This For The Money The first premise of TDD is what we […]

Five Underplayed Premises Of TDD | Video See Full Post

Underplayed: The Steering Premise In Depth

This entry is part [part not set] of 9 in the series Underplayed Premises

Time, finally, for the steering premise, from the five underplayed TDD premises. The steering premise says "tests & testability help steer design & development". What we’re saying here is that tests are first-class citizens in the mob of factors that shape our system, with a voice that counts, all the way through development. Think of the factors we take in to account when we make software. They range all over, from market considerations, to platform, from our geek skillset to

Underplayed: The Steering Premise In Depth See Full Post

Underplayed: The Chain Premise In Depth

This entry is part [part not set] of 9 in the series Underplayed Premises

Today, let’s talk a little about the chaining premise, from five underplayed tdd premises. The chaining premise says "test a chain by testing its links". Like the other premises, it’s easy to make it pithy, but it has vast ramifications about when we’re doing TDD. When we talked about the money premise, I gave a long, likely partial, list of ways TDD supports that premise. Did you notice I never mentioned the customer? TDD is for developers. The people it

Underplayed: The Chain Premise In Depth See Full Post

Underplayed: The Judgment Premise In Depth

This entry is part [part not set] of 9 in the series Underplayed Premises

The judgment premise is one of five underplayed tdd premises. The judgment premise is simple to word and vast in its extent. It says, "tdd relies absolutely on individual humans using their human judgment." you might ask yourself, "what doesn’t rely on human judgment?" but there are lots and lots of activities that are entirely mechanical, judgment-less, and geekery is full of them. We work with judgment-less systems every day. We call them "computers".there’s merit to "algorithmizing", that is, making

Underplayed: The Judgment Premise In Depth See Full Post

Underplayed: The Correlation Premise In Depth

This entry is part [part not set] of 9 in the series Underplayed Premises

Five underplayed premises of TDD includes the correlation premise. The correlation premise says "internal quality and productivity are directly correlated". Confusions and misunderstandings around this premise abound furiously, so it’s worth taking some time and working it out in detail. When we say internal quality (IQ) and productivity are directly correlated, we mean that they go up together and they, sadly, go down together. Their trend lines are inextricably linked. The first thing we have to do to parse this

Underplayed: The Correlation Premise In Depth See Full Post

Underplayed: The Money Premise In Depth

This entry is part [part not set] of 9 in the series Underplayed Premises

We talked about five underplayed tdd premises before, here’s a video & transcript. over the next couple of weeks, I’d like to take a little time and go over each of them in more depth. Today, let’s start with the money premise. The money premise says: "we’re in this for the money." TDD is fundamentally about making money. In software, we make make money by Shipping More Value Faster (SMVF). I’ve been doing, teaching, writing, arguing, and coaching TDD for

Underplayed: The Money Premise In Depth See Full Post

The Thinking Knee & Agile Practice: Beyond Coding

This entry is part [part not set] of 2 in the series The Thinking Knee

We talked at great length about how agile coding practice can be seen as combining several attempts at attacking the thinking knee, but what about agile non-coding practices. As I push towards the topic, which is it what got me started on this set of muses, I want to offer a bit of caution before we start. I’ve used the thinking-knee idea to elucidate a bunch of seemingly unconnected corners of the practice. It might seem I believe that’s all

The Thinking Knee & Agile Practice: Beyond Coding See Full Post

The Thinking Knee In Coding Practice

This entry is part [part not set] of 2 in the series The Thinking Knee

We’ve spent some time on the thinking-knee, but i’m not quite done with it yet. Let’s narrow our focus for a minute, to matters strictly around code & coding. Programmers have been thinking directly & indirectly about ways to evade or at least mitigate the effect of the non-linear thinking knee more or less forever. Dijkstra’s famout short paper, "Go To Statement Considered Harmful", from ’68, is an early example. He doesn’t invoke the knee explicitly, but the harm he’s

The Thinking Knee In Coding Practice See Full Post

Non-Linearity & The Thinking Knee: More On Fundamentals Of Agility

This entry is part [part not set] of 2 in the series Non-Linearity

So we talked about non-linearity in this previous post, wrapping it into the context of explaining why we prefer continuous integration (CI). But non-linearity isn’t just a good rationale for CI, it’s actually a driving factor for several of the practices of agility. It’s worth it to take a little more time to look hard. We’ve said that some problems are linear and some non-linear. Non-linear problems don’t just get bigger when you add more pieces, they get "bigger-er". Why?

Non-Linearity & The Thinking Knee: More On Fundamentals Of Agility See Full Post

Some Problem-Patterns I Look For

I remarked en passant the other day that I never see places where the biggest problem was sprints. Someone asked me what I do often see as the biggest problem when I walk in to a new shop? This gave me a lot of thinks. There are certainly things one sees over and over again. But most of these are small. On the other hand, there are a small number of, idunno, problem patterns, that seem much more ever-present. It’s

Some Problem-Patterns I Look For See Full Post

Scroll to Top