January 2018

Geeks And Geekery: Why I Use These Words

Okay, fine. Geeks and geekery it is. What do these words point at for me, and why do I use them? You know, asking this, there’s no way in hell i’m gonna answer without wanting to share my decidedly minority views about language. You just know that. Please be advised that I know that these are not mainstream views. Please further be aware that I’m quite familiar with mainstream views, and have made a conscious decision that I don’t agree […]

Geeks And Geekery: Why I Use These Words See Full Post

Awkward and Graceful 2 (A Recovery)

This entry is part [part not set] of 2 in the series Awkward and Graceful

Continuing last night’s wobbly muse on graceful and awkward collaborators… In the light of day, I think I see four possible responses to the situation when your new code depends on an awkward collaborator or collaboration: Ignore it (possibly just for now). Write your test anyway and suffer the expense. This is a legitimate judgment, tho one the hardcore among us have to be dragged kicking and screaming towards. Don’t automate a test for it. Again, entirely legitimate, and actually

Awkward and Graceful 2 (A Recovery) See Full Post

Awkward and Graceful Collaborators

This entry is part [part not set] of 2 in the series Awkward and Graceful

Software Programs can be understood as (potentially huge) orchestras playing in concert. Depending on your level of abstraction, you might imagine systems, subsystems, layers, packages, objects, or even functions as the individual players. (Aside: Folks often make major distinctions in these abstractions, but to my touch, they feel all the same thing, just with ever larger labels on ever subsets. and at bottom, 100% of it is Von Neumann architecture code.) For the purposes of this conversation, I’ll be thinking

Awkward and Graceful Collaborators See Full Post

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

Me And Programming Go Way Back

I became a professional programmer when I was 20, not-quite 38 years ago. Bob Martin’s back-of-the-envelope estimate of the doubling rate for programmers is that it’s been about 5 years for at least 3 decades. That means I have more time in this trade than more than 99% of the other programmers in the world today. What does that mean about me? Idunno, really. A bunch of things. It means I’m a bitter old man, of course. Even if we

Me And Programming Go Way Back 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

Scroll to Top