July 2017

Stop Using Logs Everyday

I don’t "believe" in logs, generally. What I mean is, for developers, logs should be seen strictly as a story for ops, not a development tool. I understand why ops needs to see logs. Ops is a customer just like any other, and what they need, we can supply. But I see far too many developers use the log all day long during development. Everyone from time to time does "print" debugging, of course. No technique on earth can entirely […]

Stop Using Logs Everyday See Full Post

Defining Agile: A Musing

Defining Agile Sooooo, I saw a couple folks arguing earlier about what is or isn’t Agile. That’s okay. People do that. Analytical people thrive on doing that. Anyone who’s gotten to the level of journeyfolk in any arena will seek to define that arena. All very healthy stuff. Nowadays I tend to avoid these arguments. I have my reasons. First, there is no definition anywhere on earth of anything that can’t be abused or misused willfully or not. There is

Defining Agile: A Musing See Full Post

User Stories Are Playing Pieces: The “Right Writing” Is Wrong

User Stories If you are concerned about how you write a user story, you have missed the entire point. A user story is a little card that reminds us of all the actual conversations we’re currently actually having. If the words "bathtub farting" are enough for the team to actually converse about what they signify, they’re enough for what they’re for. The very first step you take that’s away from "user story is a marker" is the road back to

User Stories Are Playing Pieces: The “Right Writing” Is Wrong See Full Post

Me & Molly & Marvelling

I’ve been having a lot of trouble getting to sleep lately. I go to bed cuz it feels like it’s time. Sometimes my body won’t settle, itching and twitching and such like. Sometimes my mind won’t. Usually it’s a mixture of both. So I get back up. But then I’m tired as hell, and it seems like I’m sleepy again, so I go back. Rinse, lather, repeat 3-5 times. Eventually one of two things happen. Either I finally manage to

Me & Molly & Marvelling See Full Post

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

Scroll to Top