Use Supplier, Supplied, Or Both?

a coding pattern; replace supplied data with a supplier or a supplier with the supplied data.

it is very common to create code with an interface like this: do( Data supplied ) . we then use the data somehow to perform our functionality, whatever a do(…) method does.

on the other hand, sometimes we create code with an interface like this: do( DataSource supplier ) , and its body is basically the same as our starting chunk, but with a prolog that asks the DataSource for the Data and *then* performs whatever do(…) does.

so when we sketch a new function, we always have to mull over which of these two is the right thing to do. and when we refactor, similarly, we have to wonder which of these two ways to go. there is not a “right” choice you should always make. sometimes the supplied is the way to go, sometimes the supplier. but there *is* a right thing you should do, and that is to pay attention to the decision, as it has a variety of potential consequences.

here are some notions to mull over that might help you make your decision.

first, consider that you can do both. you can write  do( Data supplied )  and do( DataSource supplier ) . i’ve assumed overloading, but you don’t need it, just change one of the names.) just have the supplier version contain the prologue we discussed and chain into the supplied version. note: please chain. don’t just copy the body of one into the other. doing that is purposefully injecting anti-change in to your codebase.

second, if you don’t do both, make sure that whichever one you do is the least awkward collaboration for you to test with. remember “awkwardness”? this is any property of a collaboration that makes it annoying for us to test whatever branching logic do(…) performs.

in java, for instance, streams can come from anywhere including files, but files can *only* come from a drive. if i have to write and maintain a bunch of files “somewhere else” to do my testing, well, that’s awkward. and when we have awkward tests, we don’t write/run/debug them.

third, regardless of picking one or both, is the object you’re passing in far fatter in interface than what do(…) needs to do its work? you might want to wonder if you need an intermediate object, one that is neither the supplier nor the supply, quite, but is a thin wrapper.

the business of passing around obese interfaces is extremely common in “it rubs the database on its browser” code, it dramatically increases the mental scope required to grasp and change the method. a typical case: passing a database connection (and an account id) when do(…) really just needs an account’s zipcode. you do understand that your database connection aims at a turing complete system, yes? it can do *anything* a computer can do. this issue isn’t just limited to the supplier choice. we do the same thing with supplied’s. again, you just want the zipcode. an account, whether databased or in RAM, has *dozens* of fields and operations.

you might think introducing an intermediate object is dumb, because even tho you *could* perform any of an account’s operations, you’re only really going to ask for zipcode, so why go to the trouble?

(ahhhhhh. here we strike at the very heart of the strictly technical aspects of the modern software development synthesis. change-enabling code is nearly always more valuable than shipping the next change. so begins another muse.)

the short answer is still twofold.

  1. cuz code that only gets the zipcode *must* be dead simple, and dead simple makes us go faster.
  2. when we realize we also need a) a state and b) a method to validate that they’re correct, we have a ready place to put it.

so. when you sketch a method or approach refactoring that method, consider your choices around passing supplier vs supplied vs both. consider both, consider awkwardness, consider interface width. there’s no right answer every time, but it’s almost always worth taking a minute and mulling it over.

go geek out, then.

Methods Don’t Create Health

maybe the real first wrong was the slide into “method” in the first place.

have you ever known yourself to behave in a way that is generally perceived as neutral or even positive, but in a way that is actually doing you or others harm?

Depressive Solitaire

my work makes me think a lot. and i quite often do that thinking on a low boil in the background, as i’m doing something else, most often for me playing a game. a lot of folks do this with solitaire, for instance. there is nothing wrong with solitaire, and there is a lot right with letting your mind work on something by looking away from that something. playing solitaire, or taking a walk, or what-have-you, generally neutral or even positive.

but every time i play a game, i am not thinking. sometimes i’m just playing my game and enjoying it. other times i’m doing something else altogether, something “not good”. the “not good” thing i’ve been known to do is just sit there neither enjoying the game nor doing background development, but rather, just completely shutting down while i go through the motions.

a certain amount of that seems unavoidable, for me and for us. after all, humans do background development work that isn’t detectable by us, and we don’t always know what’s going on. and sometimes shutting things down is the only healthy response, too. over-stimulation isn’t good for one, either.

but — i was a practicing hardcore depressive for over 30 years — when i am shutting it all down, it’s very often a warning sign. and if i shut it down for days and days and days, it’s way more than that. in my case, and i know i’m not alone, it’s life-threatening.

What Makes Some Processes Depressive?

what does that have to do with my opening salvo?

these cases: “just playing”, “background processing”, “healthy withdrawal”, and “depressive/OCD”. what makes one different from the other?

what makes one different from the other is the human. that is, me. it’s inside me. it is somewhat visible to me, a little visible to those who know my patterns well, and virtually invisible to outsiders, or at least invisible until dangerously late in the game.

i’m hoping you’re still with me, that you can relate to some or all of that long digression, because now i want to jump back to the question of method.

Back To The Method

have you even seen a happy team doing method X, for values of X like Scrum or XP or DaD or Prince or SaFe or — good lord, we don’t have enough characters for all of these brands?

i have. most definitely.

pick that X where you’ve seen happy healthy productive teams. i’ll just pick Scrum, since it’s so widespread and familiar to many of you. but you pick one where *you’ve* seen the good stuff.

now have you ever seen an unhealthy unhappy unproductive team doing that same method X?

i have. most definitely.

so what was the difference, between the rockin’ team and the despairin’ one? it wasn’t their method. (btw, if you’ve been around the block enough, you’ll be able to apply this to nearly any technique, whether it’s bundled into a brandname or not. i have seen test-first teams that were in great pain, for instance.)

well. what was different was the people. just as what is different from the neutral or positive game-playing and the depressive game-playing was the person. and when i say “the people,” i don’t mean the particular combo of individuals. that is, in the game-playing, the healthy and the unhealthy are both being carried out by the same me. (by the same token, i worked with that TDD-in-pain team for a while, and we turned TDD back into a lovely healthy thing for them. same people.)

same people, different state.

different state can be variously translated: different spirit, or mood, or culture, or any number of other words. suffice to say i am talking about things that are vague and inchoate but still real, internal to the team and internal to the members of the team. (i have seen many teams depressed to the point of life-threatening. it is a normal part of my work.)

Process Can’t Create Health

and here’s my point — long awaited even by me, and i’m the one doing the typing here — process, structure, method, technique, can inhibit health or it can permit health, but it can’t *create* health.

what we were after 20 years ago was health. the structures, methods, techniques all around us were actively inhibiting that health, so we sought another way.

now, that way we sought, don’t mistake me here, involved structure & method & technique, no question about it. partly because we’re geeks and we groove on that kind of shit. partly because the old stuff would not make way if we didn’t offer some new stuff.

Abandon “Process Creates Health”

the first of the four points of the agile manifesto says we value people over process. for “process”, read structure, method, technique.

when i play my game depressively, i am honoring process over people. when a team scrums depressively, or dads or safes or xps or tdds depressively, they are valuing process over people.

no part of this movement’s origin was based in the idea that “process creates health”. but everywhere we look, there are people claiming that it does and wearing our colors.

i wish to disassociate our movement with that idea that process creates health.

if you’re an “agilist”, of any stripe, please help me do this.

Coaching: How I Get Them To Do What I Want

a little more on coaching theory today…

folks ask me a lot of questions whose fundamental focus could be expressed as “how do you get them to do what you want them to do?”

so. here goes. i hereby reveal my entire competitive advantage as a professional coach, by telling you my special secret for how i get them to do what i want them to do.

i don’t. i don’t get them to do what i want them to do. i get them to do what they want to do themselves.

that sounds weird, maybe a little zen-like, i spoze. “what is the sound of the one hand getting them to do what it wants them to do?” but i don’t really mean anything very mystical by it. it connects back to the always-small-always-improve thing we’ve talked about before.

a common way to express these problems is to talk about horses and water, “you can lead a horse to water but you can’t make him drink.” (tickled memory: the algonquin round table wits use to play “use this word in a sentence” as one of their punning games. i think it was dorothy parker who used “horticulture” in a sentence this way. “You can lead a horticulture, but you can’t make her think.”)

here’s the thing about horses and water. horses *like* water. they drink it all the time. they drink it because they’re thirsty, and because it tastes or smells good, because it cools them, and it heals them, and prolly other reasons i don’t even know. when a horse *doesn’t* drink water, what does that mean? well, it could mean a bunch of things, some pretty scary, but i could collapse those into one vague hand-wave: it isn’t drinking this water just now because it does not want this water just now.

well, if i only get horses to drink when they want to, how do i even do my job at all? i mean, the whole point of getting hired to be a coach is to get horses to drink the software development modern synthesis water.

i do my job by hanging around and/or pitching in, with really good water right in my hands in just the right portions with just the right flavor. when the people i’m with are thirsty, i give them water.

and the more i manage to pull this off, the more they come to expect me to be the kinda person who gives out good water. some of them come very quickly not only to enjoy my water but to want to know where i keep getting it from, so they can get it when i’m *not* standing around.

as water-bearer’s, software development coaches *do* have certain advantages.

  • first, the water these folks have right now is insufficient or gross-tasting or both. i do know folks who work w/high-functioning teams in environments that crackle with energy & hope and embrace both learning & change with vigor. but that’s actually pretty rare in the trade.
  • second, we are usually invited in for the express purpose of coaching. they don’t know how to do it themselves, someone thinks it needs doing, and they ask us to come help.
    note: not *everyone* in an org thinks it needs doing. 🙂 but usually the someone who hires me packs some weight, and my victims have the general idea that they’re supposed to attend to me a little. as it happens, i turn out to not be just another boss-y guy, and i turn out to be occasionally useful, so i get the *good* part of being hired by a heavy without the *bad* part. by and large.
  • third, as coaches we are not responsible for all the things these teams are held responsible for, which gives us lots of time to work on preparing water and watching for thirst.
  • fourth, we generally have far broader experience in water-procurement than our teams do. i know a lot of ways to get water. i know a lot of different ways to flavor water. i know a lot of kinds of thirsty.

so, let’s back away from this water metaphor thing for a minute.

advice: develop a catalog of “better-than-this” changes. the job is not to install the one best way to make software. (there is no one best way, but that’s for another day.) the job is to make things *better*. and even a little better is better.

advice: focus in the beginning on small owwies that they agree are owwies. it’s both doing your job, making things better, and it’s generating “capital” you can use later for larger owwies or owwies they don’t yet know they have.

advice: *collaborate* *with* *them*. “coach” is not a synonym for “boss” or “teacher” or even “expert”. work on your collaboration skills more than any other thing.

advice: be kind to the victims and kind to yourself. forgive both parties as often as you can. neither you nor they can always be open, strong, decent, right, or fast. in the AA rooms, we say, “time takes time”. patience is one of your most important resources.

advice: look out especially for the times when they want to do something you also want them to do, and be ready with a small concrete step that will pay them back quickly.

anyway, that’s what i got. how do i get them to do what i want them to do? i don’t. i get them to do what they want to do.

How To Test Depends On What To Test: Money, Chaining, and Steering

to have a serious conversation about *how* to test, we have to start by considering *what* to test. as a microtesting TDD’er, what i want to test is *our* *logic*.

the money premise of TDD reminds us we’re in this for the money, that is, the primary purpose of TDD is to enable us to ship more value faster.

deciding what is “value” is not a TDD task. the larger agility certainly asks us to make hard choices about value, but by the time we TDD those (always temporary & dynamic) decisions have already been made.

what i am saying is bold, and it will not surprise me if it surprises you, even if you already are a TDD advocate.

i am saying that there is no “change this code in a way that requires branching” task with scope bigger than half a day — in its entirety, in perpetuity — that we won’t do faster using microtested TDD, assuming you a) know how and b) have the TDD tool at the beginning. it absolutely does not matter *why* you or your team or your org has decided you need to change code in a way that involves branching. that matters to you, your team, or your org. it doesn’t matter to the assertion i am making.

more features? TDD can do that faster. fewer bugs? TDD can do that faster. get this thing to alpha so we can see if anyone’s dumb enough to buy it? TDD can do that faster. see if complex variant X is performant? TDD can do that faster.

it’s not because TDD is the end-all and be-all of ll possible situations. it’s because TDD is the fastest current known technique for changing code in a branchful way, and all of those depend on changing code in a branchful way.

i reiterate: i am assuming a) you know how to do it, b) you have your rig ready to go at the start. those certainly aren’t valid assumptions to make everywhere all the time. but why would you bother learning or setting up if you weren’t gonna get a payoff?

the payoff — i *have* theory galore, but i am not coming from theory here but from practice as a hardcore working geek — is that *any* code changing that requires even modest logic goes faster with TDD. we don’t care about what/why the value is in this code-changing context. we only care that it’s code-changing in a situation that requires us to combine logic.

another way to say this: i am interested in TDD’ing any code we wrote that has a local mccabe complexity > 1. if you don’t know what mccabe complexity is, there’s a thing called google, but the short phrase is “number of possible paths through the code”.

many of us start a new language by learning how to print “hello world” to the screen. if it’s a console program, that’s a one-liner. in its entirety, it calls a library that is built in to your programming language. it has a local mccabe complexity of 1. there’s only one path through it. no branching, no logic, no nothing. it is basically an exercise in typing. i do not wish to test it.

wait. that’s not right. it’s not that i do not wish to test it. it’s that it’s cheaper for me to run the program and see if it says “hello world” using a device i call “my eyes” than it is to write a test, even if i know how to test & i have a rig. and because it has no branches and depends entirely on the system library in nearly every respect, i am happy to use my eyes one time and walk away.

(aside: occasionally we confront situations where *transitive* mccabe complexity becomes important. those situations inevitably involve mutable state, which is one reason we don’t like mutable state.)

now i will run out of steam here in just a minute. but i want to complicate this picture a very tiny amount, and in so doing, we’ll move from just the money premise to the money premise plus the chain premise plus the steering premise. spoze i sometimes want to print “hello world” and sometimes want to print “hi mom!”. i have to *branch*. i have a condition — let’s say i have another library call coin(), like print, that returns heads or tails.

the first thing you note, the mccabe has gone to two. there are now two paths through the code. second thing you note, we have *our* *logic* in the game now.

it is at this point that you realize you haven’t the slightest ability to easily capture the output of those print statements. (you have encountered, in fact, your first awkward collaboration.) enter the chain premise. we stop testing the *app* and test a part of the app. we don’t really want to test print or coin at all. we know they work. (if they don’t work, we have bigger problems.)

we want to test our logic. we want to be sure we do the right thing on heads and the right thing on tails. so what if we just test our logic, and not test the whole thing? uhmmmm, nothing. we got nothing. the fact of the matter is that those damned print statements are in there screwing up our ability to test just our logic.

enter the steering premise. what if those print statements were *not* intertwined with our logic that we want to test? then we could use the chain premise to test just *our* *logic*, and to hell with testing a system library call.

the only way to do that is to change our code. rearrange it so we first decide what to print — our logic — and then print it, a thing we trust works and can eyeball cheaply.

to test that logic separately we need it separate, in a function.

the tests we write are two, one for each local mccabe path through greeting.

we have *steered* our design. we took into account what we wanted to test — *our* *logic* — and we changed our code so that we could test it easily.

we started by considering what to microtest. we want to test *our* *logic*. we don’t want to test the app. we don’t want to test the library. we want to test the parts where we write code that branches, and we want to do it cheaply enough that it makes us ship value faster.

the money premise reminds us this is more value faster. the chain premise tells us to test parts rather than the whole. the steering premise tells us to change our code to make that possible. there are other problems. and we have answers for them, too. but to start TDD, start there. you will go a very long way. money, chain, steering.

Avoid Implementation Inheritance: GeePaw Goes All Code-y

so, day off before travel before onsite, playing ONI, having fun, but i want to muse about a highly geeky matter anyway…

do you ever override in a sub-class a method that’s already implemented in a super-class? i want to recommend to you a policy of avoiding that like the plague, whenever you can.

i will go further: i avoid, maybe not as much as the plague, but surely as much as the measles, even deriving any sub-class off of any super that has any implementations at all. (anything not a “pure virtual base class” in c++, “interface” in java. in languages that have no such concept, any super-class that has an implementation other than “throw new ForgotToOverride”.)

i came to this philosophy very slowly over an embarrassingly large number of years. i say “embarrassingly” because, nearly as soon as i came to it, it made itself clear almost immediately how much better/stronger/faster/kinder my resulting designs are. i came up through the OO revolution, you see, and i’m a confident and capable OO geek, surrounded by this thing, i’ll call it “implementation inheritance”. it was the air i breathed.

when i started TDD, i had an enormous amount to learn just in first the basics and then the intermediates. it took some time. as it progressed, i learned about a kind of meta-pattern i’d been engaging in for years & years. it’s a hard one to see, this meta-pattern, and that’s what took me so damned long. it’s trading the major value of getting what i’ve elsewhere called “rigorous” results for a variety of lesser values that essentially amounted to local convenience.

or, maybe, that’s not quite right.

let’s try another take: i was trading to get a kind of local appearance of convenience, and in so doing giving up an actual *global* improvement in my ability to ship more value faster.

and the worst part of it was, i wasn’t even getting that much local feeling of convenience. just a little. and i was giving up a *lot* of global value-shipping speed. and this wasn’t just one feature of my coding technique, i was doing it all over the place in myriad ways. TDD slowly helped me find those ways and choke them down, one by one. i will never not think of it fondly for doing that. one of the things i was doing, tho, was being what i thought was a facile and even gifted — i get perky at times — object-oriented programmer. i used implementation inheritance heavily.

the benefit of implementation inheritance is dreadfully obvious: it’s the fastest possible way in a statically typed language to re-use code you or someone else already wrote. and if you’re good at it, i was, you could carry it around with you all over the place, like an overloaded saddle-bag draped around your neck, and never even notice it, except occasionally if you needed to feel good about yourself.

TDD — as always i mean by this “the modern software development synthesis” broke me of a lot of “good programming practice” habits that were not in fact good programming practice, but it took me a really long time to get past this one. i was already pretty much a TDD master before i finally set it aside.

why set implementation inheritance aside?

  1. you almost never need it. that is, anything you can do with it and a modern optimizing compiler you can do just as well without it. the sole exception i’ve found is in some obscure performance situations that, trust me, neither you nor i are likely to find outselves in.
  2. it complicates in a particular way: you see, implementation inheritance impedes quite sharply what i regard as the central skill or discipline of being able to ship more value faster, the management of mental scope. every implementation inheritance — every single one — creates a hole in the little conceptual box of “the code right in front of me”. and it does it implicitly, almost invisibly. it is a guaranteed violation of “locality of reference”, the ability to see what you need right when you need to see it.

how did TDD help me finally see this? TDD helped me to see that implementation inheritance was undesirable because it made me *think*, *more*, about stuff that wasn’t *there*. well. mama dint raise no thinkers. thinking more about stuff that’s not in front of me is exactly the opposite of managing mental scope. when i have to TDD implementation inherited classes, tho, that’s exactly what i have to do. and the thing is? half of that thinking has almost no relevance to the current value i’m trying to ship faster.

maybe you’ve never seen hardcore implementation inheritance. i see it all the time, particularly in older larger codebases dominated by a so-called “senior architect” who memorized the GOF book in ’95 and hasn’t shipped value in the last 20 years.

but if you’re wondering, here: this chart — part 1 of 3 — is illustrative. almost none of those boxes is an interface. at the bottom of that dependency tree there are leaf nodes that have upwards of seven or ten *implementing* super-classes. every one of them with dozens of methods, every one a partial override of its super.

we don’t ship more value faster by juggling more balls, but by juggling fewer. implementation inheritance always adds balls to what you have to juggle in your head while you’re working.

so let it go. if you’re having trouble seeing a new design without it, come find me, or any of dozens of serious TDD’ers out there. we *like* solving design problems. we do it the way people work crosswords in the sunday times. ask us, you’ll see.