Geekery

The Driven Premise

EDIT: This premise has been renamed the "Steering Premise", you can see the full video breakdown here. The Driven Premise Here’s an illustration of the most basic principle of TDD, what I call the "Driven Premise": there once was a queen who had a thousand consorts, each more brave and handsome than the next. But only if you lined them up that way. The driven premise says that tests & testability are first-class participants in design. When they are, then […]

The Driven Premise See Full Post

Assumption-Boxing is Harmful

Assumption-Boxing I’m thinking of maybe a new geepaw coinage: something like "assumption-boxing". This is when we frame a problem with an assumption that narrowly limits (boxes) the range of solutions. A real-world example we’re all familiar with: "Optimize meeting structure to exchange status reports on individual’s sub-projects". Do you see that "meeting structure" is a built-in assumption in the problem, & that it greatly boxes in the kinds of solutions we can have? Long before most current geeks had seen

Assumption-Boxing is Harmful See Full Post

Turn Preasons Into Reasons

What are preasons? A remarkable amount of geekery-advice comes in the form of rules & slogans accompanied by appealing. intuitively correct, theoretical reasoning using simple logic applied to pre-existing abstractions. I’m gonna pull a GeePaw-ism here and relabel "appealing, intuitively correct, theoretical reasoning using simple logic applied to pre-existing abstractions". I’m gonna shorthand these to "Preasons". So. We get a lot of preasons in our trade. And they’re applied at every level, including but not limited to Coding, Designing, Tool-Using,

Turn Preasons Into Reasons See Full Post

The Drive To Help

Have you ever noticed how much children love to help? Modern motivational theory offers us a triplet: purpose, autonomy, and mastery. (PAM) children helping surely excites P and M there. As adults we’re all slightly less desirous of helping. I attribute this to two factors. First, there’s a lot less M in it for me usually nowadays. I already know how to, say, sweep the floor, and I’m less driven by mastery. Second, we bring more of our own P

The Drive To Help See Full Post

Test It Where It’s Easy

Test It Where It’s Easy A basic mantra: don’t test things where they’re hard to test. A very basic application of this mantra comes up for almost every noob TDD’er: "How do I test this complex private method?" The answer is simple: make it not private somewhere else and test it there instead. If your private is truly complex, it’s truly interesting, and needs testing. But ask why it has to be private? The most common answer: "I don’t want

Test It Where It’s Easy See Full Post

Standardize-By-Problem, Live Vertically

The Problems with Enterprise Standards I’ve been thinking lately of how much "enterprise standards" ruin our lives. When I coach in VBCA environments, I confront this problem more or less constantly. The standards can be enterprise tools, enterprise negotiations, enterprise processes. I see two factors in this. 1) solution-locking definitions, and 2) inadequate coaching reach & action. Solution-locking Definitions Improper solution-locking definitions is my best (bad) phrase for this: we specify standards by solution, not by problem. Let’s take an

Standardize-By-Problem, Live Vertically See Full Post

Scaling Software

I spoze we should talk about scaling. There are a bunch of branded solutions to the puzzle of how to organize development of large apps with large teams. I don’t know of one that is worth the bits consumed in its logo. Yesterday I mentioned assumption-boxing, that’s when we express a problem in such a way that we bind ourselves to one or a small family of possible solutions. The assumption in all the scaling brands I’ve seen: that effectively

Scaling Software See Full Post

Pain And TDD

“We were doing TDD just like we’re supposed to, but at some point it started hurting, so we not only quit, we told everyone else on the interwebs that TDD doesn’t work.” I met Kent Beck after a couple of years reading and writing around him, at the first ObjectMentor Extreme Programming (XP) Immersion, a wonderful week I’ll never forget, where I met so many awesome geeks and coaches. (Kent Beck, Mike Feathers, James Grenning, Bob Martin, Ron Jeffries, Martin

Pain And TDD See Full Post

Making Complex Changes

It happens that there are sometimes very complex changes you want to make to your code. These might involve changes to dozens of existing classes, and to the heirs of some of those, too. How do we approach this kind of situation? Recall that managing mental scope is the very heart of programming well. But any such change is sure to blow all hope of narrow mental scope right out of the water. We can only manage mental scope if

Making Complex Changes See Full Post

How Much Design? When To Start & When To Stop

Alright, pre-coding design. By that, I mean, the serious thinking one does before one starts typing code into the computer. The first puzzle of pre-coding design is to identify when to start & went to stop. Start When You Have A Story When to start: when a story has been selected for implementation. That starting condition will be tricky for noobs, so let me blather for a minute. There’s no time to discuss stories in general, but in short, by

How Much Design? When To Start & When To Stop See Full Post

Scroll to Top