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.

Coaching? Like People!

Hey, there, it’s GeePaw! And you are watching the first ever GeePaw video aimed specifically at coaches. I hope you like it.

Do you know what the first absolute prerequisite for being a successful software development coach is? You have to like people.

You have to like people. You have to like their style. You have to like their resistance. You have to like when they do the thing you want them to do. You have to like when they don’t do the thing that you want them to do. You have to like people.

We get into this business because we’re very hot on a system, or a method, or a technique, or a something, and we want to share it with everybody.

But it’s really easy to get caught up, caught up in the system, caught up in the method, caught up in whatever flame war is running around the building today. It’s important to remember, though, the secret requirement for all successful coaching enterprise, is to like people.

What I’m Not Saying

Now, before we get very far, we have to address a couple of things I’m not talking about. I am not suggesting that you have to be an extrovert, a person who gains energy rather than losing it by being around other people. You don’t have to be an extrovert.

And I’m not suggesting that you have to be some sort of rainbow-farting unicorn floating up in a blue sky with just enough fluffy clouds in it to prove to you that, truly, every day is a beautiful day.

You don’t have to be either of those two things. I’m not either of those two things, not even by a stretch. But I like people. I like how they think. I like what they smile about and what they cry about. I just like people. What can I tell you?

And if you’re going to be a successful coach, you have to do that, too. Now, listen, I’m a pro. And I always find something nice to say about every team that I work with, because it’s a perfectly ordinary and healthy part of the job. I admit, sometimes, it’s a really big stretch. Gosh, you know, you guys just have the best shoes of any team I’ve ever worked with.

But truthfully, I like people.

I like knowing how so-and-so met her significant other. I like knowing why so-and-so became a geek. I like knowing what happened at the house last night over dinner that was funny? I like knowing that my friend buys tons and tons of video games but never ever has time to play any of them. All of those things, I like about people.

I like people because we’re so messed up and we try so hard.

That’s my secret to liking people. That’s what led me to like them so much.

We’re so broken. I’m broken. You’re broken. Everybody around you is broken. And yet, we’re all trying so hard to be who we want to be, to do the right thing, to be kind, and strong, and fast, and smart.

And that is what let’s me like people so much.

Play More Favorites

Let me ask you something. Do you ever play favorites? Are you ever a little warmer to somebody else because they’re one of your favorites, a little more tolerant of them, a little more cheerful around them, happy to see them, happy to listen to them, happy to talk about things that don’t have anything at all to do with work?

So do you play favorites?


Keep it up. Play more favorites. Pick more favorites to become your favorites.

Remember The Last Time?

Do you remember how it felt when you were listened to, when you were asked, when you got help from somebody else, or you gave help to somebody else, when you were regarded kindly by someone?

Do you remember how powerful you felt, how much stronger, how much more whole, how much more hopeful about what was coming in front of you, and about the possibility of you actually pulling it off?

So. Dig it.

Do more of that.

I’m GeePaw, and I’m done.

Coaches: Whence Confidence?

coaches, we all know that confidence is key, yes? it’s not the only key, but it’s key, especially in the beginning.

people look to you for ideas, then. and they’re lookinig to you for a number of reasons, but one of those reasons is because they think you’ll have some. and early on, there’s very little reason for them to think that. they don’t know you, they are guessing. and that perceived confidence in them is matched by an internal confidence in you. it takes a lot of nerve to stand up on your hind legs and offer an idea to a group you don’t know well.

so where’s that confidence come from?

well, you could just know all the things. if you knew all the things, you’d always be right and could always be confident as a result. you could also just pretend to know all the things, of course. that’ll help with their sense of your confidence, but it won’t help all that much with yours. i know some of the things pretty well, and some of the things kinda, and a whole lot of the things not very much at all.

where’s my confidence come from?

one place it comes from is my past successes and failures, which are plentiful. both have lent me a great deal of confidence.

  • successes in the past give me a little confidence because they were successes, but they also lend confidence at a higher level because, frankly, they amounted to very little in the grand scheme of things. they are relatively unimportant.
  • and failures might seem to subtract confidence, which they do, but again, in the grand scheme of things, they just don’t matter that much. i’ve failed more than i’ve succeeded, and i’m still here. still hungry. still beloved by some. still at it.

it’s strange to say that my confidence comes in part from the relative insignificance of my choices. but strange doesn’t make it untrue.

another place my confidence is rooted is in my extreme capacity for doubt. again, rather strange. but i gain tremendous strength from knowing in advance most of what’s wrong with my ideas. by the time my idea gets out, it’s already been hit and hit hard by my very own doubt-magic. to a remarkable extent, i already know what’s wrong with it or what might be wrong with it. this means i’m very rarely surprised or troubled when others critique it.

i also get my confidence from two kinds of “meta-“. essentially, the confidence is inherited from my process. it’s not that i have so much confidence in the value of my idea as that i have so much confidence in the value of my idea-valuation process.

i call the first meta- “do to know”. once i get an idea past a rudimentary scratch & sniff test, once i establish that it’s not definitely wrong or evil. i turn my attention to splitting it into steps that attempt to reap partial value from it. i do one of those steps, and i get to see if i got the partial value i was hoping for. i am doing the thing — in steps — to know whether it is valuable or not to do the thing. “do to know”.

the second meta- ? i have nearly complete confidence that the people i share my ideas with will take the idea, lose the fat, and cash in on the protein with tremendous vigor and enthusiasm. this gives me confidence because i don’t have to be that smart. even if i’m the smartest person in the room, *we* are smarter than *i* am, if we’re just given the chance to be.

as long as my process gives us the chance to be, we’re as good to go as we’re gonna get. “as we’re gonna get” is an important clause. i’m not saying our ideas always work, or that even if they work they’re the best. i’m saying, we live in the heideggerian “thrown”, and inaction is an action, and being right in advance just is not within our reach.

we have no choice but to share ideas and try the ones that aren’t definitely wrong or evil.

so that’s where i get my confidence. it comes from insignificance, doubt, do-to-know, and community. it doesn’t always work, because nothing always works. but it works often enough.

where do *you* get *your* confidence?

The Rigorous Playpen

i’m bettin’ u already got some code. if yer a geek in a substantial code base in an org w/more than a half-dozen other geeks, i’m bettin’ u already got a *lot* of code.

in your team’s head, if not somewhere on an out-of-date piece of paper, there is a picture of “our code”. i want to draw a box somewhere where there’s room in that picture, and i want to label it “rigorous”.

let’s call it the rigorous playpen. and what we want to put in that area of our codebase, is only file-pairs about which we can make this statement:

this code (T) tests that code (P). if u can break our app in that code w/o this code telling u u broke it, call us, any time day or night, and we will come running.

i have some questions & comments about this idea. do you get it? that is, does it seem pretty clear what we’re asking to go in the rigorous playpen?

under what circumstances might you move one of your file-pairs in to that category? it would seem to require a substantial amount of judgment & experience to designate some file-pair as being in the rigorous playpen.

if we had a rigorous playpen with some code in it, what might change about how we do things now?

i’d imagine several things would change.

  1. we would be far less likely to go there first in a brushfire. this is like our doubt that the String class from our library is fundamentally broken, rather than the index we passed to ‘substring()’. nobody *starts* by debugging String.
  2. we would onboard newbs by finding work to do in the rigorous playpen. both, changing code P and changing code T, both with our assistance & support of course.
  3. we would orient ourselves *outside* the playpen to buidling code that was readily playpen-suitable from the very beginning. this is the steering premise of TDD.
  4. as we brought more and more of our code to the playpen, we’d get better & faster at doing it.
  5. as we brought more and more of our code to the playpen, we would fear deployment less and less.

a question emerges almost immediately: how much is this going to cost?

the answer: a good deal less than you think, because the payback comes at you high and fast. a good deal more than you think, because you have to change how you think — how you *feel* — about building software.

No One Way: GeePaw On Method

when i was geek-young, not quite forty years ago, i worked in a tiny two-person shop, and we were entirely without “method”. we just wrote code. at that time, there were plenty of analysts of geekery, and they were certainly writing about how to geek, but 1) their ideas were seen as more of a bazaar than a cathedral, and 2) most of the trade did exactly what we did at good ol’ MIS.

(chris martz, or jan, if you’re out there somewhere, i would love to make contact. i have never properly expressed my profound gratitude. i internet-stalk you from time to time, but no luck so far.)

in the period from about ’85 to ’95, a lot of proto-brands of methods started to emerge. most of these were tightly tied to direct geekery rather than the larger trade. as ideas about how to write code got stronger, they widened their scope, and became ideas about how to run the whole trade. i myself used the Booch method, later unified with jacobson & rumbaugh to create the Rational Unified Process[tm]. [no, literally, tm.]

it’s not actually clear to me that most geeks use any method more formalized or nameable than what i started with back in 1980. and even those whose orgs *claim* to use one, seemingly very often don’t.

there is a plethora of methods these days. in the circus called “agile” they seem to multiply like bunnies. proto-brands have become full-on brands. flames abound, and much gnashing of teeth, tho i’ve hung with various leaders in this scene for many years, and a lot of what might seem to a noob as internecine conflict is actually just joyful intramurals. (ex: london & chicago school TDD).

y’all know i abhor hashtags for any purpose other than to create temporary news channels for breaking events. i’m especially resistant to those tags that reek of sloganeering. i don’t find myself in need of threads whose intent is to unify but whose result is to divide.

but if i were to stake out a hashtag it would be # NoOneWay.

when i was first learning to teach, my constant debriefer was my beloved wife virginia, a master teacher. every day i’d tell her about the day and throw out something that “went wrong”. at this point, she would suggest — i am not exaggerating for effect — anywhere from 5 to 15 things to try in class that were different from what i had tried. for her as a master teacher, it somehow never entered her head that there could or would be One Best Way to trigger the light bulbs in a class of students.

this was a revelation to me, building a slow tire-fire in the dump of what passes for my consciousness. and over a very long period of time — apologies to my many intervening victims — the message got through. and once i got it, with teaching. i began to see it much more with geekery, conceived both narrowly with “writing code” and broadly with “shipping value based in software”.

i don’t want you to think — heh, how could anyone possibly think this of me of all people — that i don’t have opinions, and strong ones, about what things have worked and not worked, for me, for the teams i work with, and even for the larger trade. i certainly do.

but consider some method X. maybe it’s a method for writing a line, or for dividing software into efficient arrangements for mental scope, maybe it’s for obtaining viable working definitions of “shipping” or “value”.

and consider method X’, which is just method X with some small change.

here’s the thing. there is no One Best Way to write a line of code, or divide software in chunks, or find out what people would like software to do. there is no Method X that is the One Best Way. Maybe there never will be one, or maybe the world will change, but for now, we are without a Method X that is a Method One Best Way for any of these things.

so, what’s a girl like us to do?

take whatever you’re doing now and label it method X. if it’s working great, great, make an X’ method out of it and try that and see if it gets even better. if it’s working not-great, find something different, method Y, and try *that* for a while. the geek trade is absolutely surfeited with ideas for both method Y you haven’t tried and method X’ you haven’t tried.

read widely. try things. don’t be afraid to try X’ and decide you still like X better or decide to try X” or even a different ‘. and please, don’t *stop* doing X’ methods just cuz you haven’t found one yet that’s really better than your X. not only is it extremely likely that your situation is only local in time, but it’s extremely *un*-likely that you have discovered the X that is the One Best Way.

the road to hell is lined with great parking spaces. don’t park.

last thought for this muse: isn’t geekery just about the *best* thing?

h/t my friend @onealexharms for the morning tweet that started me down this one.

The First Metric: How Are You Feeling?

of all the routine requests i get from clients, the one i find most difficult to deal with is this: “help us choose a metric so we can tell if things are going well.”

the problem is that “numbers as health indicators” is *so* deeply embedded in our worldviews, *so* deeply correct on paper, and *so* deeply counter-productive in every case i’ve seen in practice.

think about your own health for a minute. is it a 9 or a 3? while you sputter away trying to answer that, let me point out some of the difficulties in making such an assessment.

  • difficulty: my “health” rests in a huge variety of factors, some easily measured and some not so easily so. in order to come up with one number, or even five numbers, we will have to do make some pretty sophisticated judgments after some pretty sophisticated analysis.
  • difficulty: my “health” varies temporally due to externalities like recent injury, the flu, the six straight weeks i’ve spent in a hotel, and so on. we’ll have to make sophisticated judgments after sophisticated analysis.
  • difficulty: my “health” includes factors not one person on earth knows how to assess objectively, like whether i’m nearing the borderlands of churchill’s black dog, or whether my mom just died. hmm. we need some sophisticated judgment after sophisticated analysis.
  • difficulty: *my* “health” has key indicators that are not the same key indicators as *your* “health”. if we’re to compare these, dagnabbit, sophisticated judgment & analysis will be required.
  • difficulty: for a 100 years, several times in the last twenty years, a variety of expert-consensed health indicators have been challenged, overturned, abandoned, and replaced. parsing that turmoil to settle on figures would need, you know, sophisticated judgment after analysis.

anyway, if you’re done sputtering, just give us the number. is it a 3 or is it a 9? is it 3.782 or 3.105? c’mon, c’mon, kid, i don’t got all day here, i have powerpoint to edit.

  • difficulty: knowing my “health” is 6.322 tells neither me nor you what we want, could, or should, actually do about it.
  • difficulty: the relevance of a health metric depends entirely on the relationship between me, my health, and the origin of your interest in it. you guessed, sophisticated judgment after analysis.

if you’re reasonably good at assessing trends, you might have noticed a trend in all these difficulties. (if you’re not, then why did u even ask me for these numbers?) that trend is towards sophisticated analysis followed by sophisticated judgment.

well, is *anyone* good at assessing health? yes. i can think of two groups that are quite good at assessing health: medical professionals and health insurance companies. (neither is perfect, both are quite good at it.)

how do doctors & nurses assess health? well. they build relationships with their patients, and make delicate subtle judgments using 1) experience & preference, 2) your reports, and 3) some extraordinarily expensive & complex local detailed tests.

insurance companies do it differently. they use huge aggregates and monte carlo analysis and data-mining and *staggeringly* complex mathematical models to do it.

these differences make sense. insurance companies care about your health because doing so lets them maximize their gambling profits across a huge range of bets. doctors & nurses care about your health because of other reasons.

still sputtering? lord help me, it’s a simple question. WHAT IS THE NUMBER OF YOUR HEALTH!??

let me ask a question. when you “don’t feel good”, are you more likely to see a medical professional, or more likely to see a health insurance company?

i thought so.

notice two things about going to your medical advisor.

first, your medical advisor is a full-time expert on health who invests heavily in an actual ongoing relationship with you, and that costs money. (if you’re an american, it normally costs more money than you have.) second, your medical advisor begins virtually every interaction in one simple & straightforward way, by asking a question: “how are you feeling?”

so. i have a client right now who is asking me — all clients with more than three geeks ask me this sooner or later, sooner at the vbca’s, later at the smaller outfits — how can i get a number to tell me our health?

“how are you feeling?”

Coaching? The First Pre-Requisite Is To Like People

do you know what the absolute first pre-requisite for being a software development coach is? you have to like people.

sometimes we get so involved and committed to method, or technique, or whatever current flamewar rages around the building, it can be really easy to lose track of this fundamental requirement.

  • i am not talking about being an endless fount of loving kindness, a rainbow-farting unicorn drifting amongst the few fluffy clouds that just serve to highlight the great beauty of every day.
  • and i am not talking about being an extrovert — one who gains energy more than loses it by being around other people.

anyone who knows me knows i am neither of those two things.

i’m talking about *liking* *humans*. their quirks and tics, their style, their hopes, their worries, all the stuff that make us people and not machines. i’m a pro. i never work with a team without finding something nice to say about them. and i admit, sometimes that’s something like, “gosh, you folks just have the *best* shoes!”

but i actually really enjoy the people i work with. i like learning about their weird-assed hobbies, their night-coding project, the path that led them to geekery, how they met their SO, and on and on. i just like people. we’re such a mess, and we try so hard.

so let me ask you this: do you play favorites? Good. Play more of them.

remember what it’s like to be attended to, smiled at, to get help and to give it, to be asked, to be regarded kindly. remember how *strong* you feel when those things are happening? dig it. do more of that.

TDD & The Geek-Young: Is Tdd Right For Noobs?

possible causal point for a failure to value TDD: geeks thinking the main source of bugs in professional software is not handling the main case successfully.

in any feature in any app, there are one or more primary cases. a given story is likely to be concerned with one of these at a time. when you’re geek-young, the great challenge is just to close out the primary case. hell, you barely learned the syntax, you’re just learning the library-set. just getting that primary case running is a big deal.

it takes a while, but with some practice, these primary case problems get easier and easier. you learn the syntax for real. you’ve used enough of the library to suspect or increasingly know how it was intended to be used. you are getting stronger, and that’s great. you find yourself making solutions in your head before you’ve even heard all the problem. and altho that has its own risks, you generally are making headway all the time.

when you go pro, tho, three factors emerge, all of them based on size.

because your app is larger, there are more people changing it, more cases to grasp, more things to remember.

  1. more people means more worldviews. assumptions you’ve made in your code are quite likely not the assumptions made in theirs.
  2. more cases to grasp means more possible code-paths. assumptions you’ve made about when and where and why your functionality is being called are far more difficult to make.
  3. more things to remember means slower and slower thinking. human brains are optimized for a very narrow bandwidth. no matter how much you resemble an encyclopedia, sooner or later you become nearly paralyzed.

and somewhere in this not-quite-so-geek-young phase, you will hopefully begin noticing that standing up the isolated main case really just isn’t that hard, comparatively. you bone up on design, which isn’t mostly about solving isolated main cases anymore. it’s about a new level of the game. (like when you finally realize potting simple pool shots isn’t the hard part of pool, or that bouncing between knit and purl isn’t the hard part of knitting. there are lots and lots of games-for-a-lifetime, and geekery is one.)

after a while spent learning the patterns and their beautiful variations, experiencing the joy and despair of walking around chanting “it’s really just an X. *everything* is just an X. it’s X’s all the way down!” you reach yet another game. you begin to understand how much time and energy you are spending on problems caused by assumption mismatch and tacit knowledge and trivial one-liner flaws.

TDD — really a shorthand for me for “the modern synthesis of software development” — offers a variety of ways to mitigate or even eliminate that pain. and as you adopt it, your successes increase, and your failures decline. and blammo, you’re a pro. this isn’t a switch, it’s a process, and it takes time. fortunately, you have time, cuz it pays back almost immediately.

and now you’re in a place where you can look back on those other periods and ask, would TDD have helped me even then?

my answer: yes, oh hell yeah. because those assumption mismatches, tacit knowledge failures, and one-liner flaws, THEY WERE COSTING ME THE WHOLE TIME. i just couldn’t see it. “just make the isolated main case actually run, please lord please,” was all i could attend to. tho i felt like the isolated main cases were the hard part, i was wrong. the hard part was *still* what it is now: assumption mismatch, tacit knwoedge failure, one-liner flaws.

i’m old enough to have climbed many mount stupids, and the odds are good that i’m climbing one just now. but at my current stage in the game-for-a-lifetime called geekery, i believe that TDD would have walked me through all the earlier stages far faster.

TDD is so powerful because it lets you kill off so many distractions from “just get the next main case working.”

Sync Points Reduce Our Trade’s Effectiveness

companies spend a great deal of time and energy seeking to get their teams synchronized. several forces motivate these efforts. it’s worth taking a second to look at these.

  • one force: the belief that synchronization provides steering points. the notion here is that since we’ve just synchronized, now is a good time to react to the market and adjust the direction in which the project is headed.
  • second: the belief that no given team is able to do all the “vertical” work needed to accomplish some business goal, to go from silicon to screen and back again, with reasonable optimality, e.g. turnaround time, excellence, safety, and so on. (this belief is often buttressed by actual organizational barriers. most notably the horizontal layering of teams to resemble whatever horizontal layers exist in the app or its technologies.)
  • third: synchronization points give us an evaluation opportunity for the market, but they also give us one for the teams. it’s a convenient time for us to reward, spank, and re-org our team layouts.
  • fourth: sync points let us view longer term plans as composed of little segments that we morph into “work buckets”, which we can then “fill” and produce some sane estimate of when a large-scale deliverable might ship.

these beliefs, and some related others, seem to lend tremendous support to the idea of building software development teams around the central idea of synchronization mechanisms. the synchronization schemes form a widespread mainstream in the trade. they’re especially prevalent in vbca’s. there, they tend to go hand in hand with a variety of “standardization” efforts.

i contend that these synchronization ideas — writ especially large in the vbca world — create a tremendous net-negative impact on software development all over the world. they are not just not needed, but are actively counter-productive. i think they are wrong or wrong-headed.

i spend large amounts of time embedded in various “agile” organizations. most of these are “scrum”. these orgs almost uniformly introduce sync points at 1) 1-2 weeks, 2) 12-16 weeks, and 3) 52 weeks.

(note: those quotes are expressly an anti-invitation to discuss the myriad ways those orgs are not actually doing “real X” for any value of X in vicinity of the movement we share. i am bored of that conversation, and will require free scotch to bother to pretend otherwise.)

let me offer a few points about this synchronization concept & its implementation in these orgs. before i do, tho, i will make a statement that may trouble some listeners. that’s okay, it troubles me a little, too. but i’ll tell you now and u can decide whether storm off early. (1/2): i’ve spent 40 years in professional s/d, and 20 years embedded in the agile movement as a leader. i’ve worked in dozens of orgs, from ma & pa to fortune 10 companies, on every kind of s/w there is. i am coming from actual practice & experience.  (2/2): and maybe that’s all there is to say. i cop to my well-known arrogance. please don’t come at me with a textbook or a well-designed slide, your week-long class or your scant years doing the same thing in the same org. i just don’t have it in me today.

okay, some points, for those of you tolerant enough to hang in this long.

point: synchronization mechanisms are never free. by its nature — by its very definition — synchronization breaks flow. it introduces wait states and restart costs. wait states are periods where we stop working because there’s not enough time left before synchronization for us to squeeze anything else in. restarts are periods right after synchronization where we re-gather our focus and seek to re-find flow. if the syncing mechanism itself is expensive: i routinely see 1.5 days given over to syncing at 2 week intervals, one is easily giving 20, sometimes 25 percent of one’s productivity over to the mechanism. this is a staggering cost. we should make sure the benefit is worth it.

point: the ideal site for steering a small team is any time they’ve finished one small piece of work, before they start another. one does this in a hierarchy by giving your direct reports larger-scale direction and leaving them to decide how/when to intervene inside their teams. this is not easy, which is why you are well-paid to do it. it requires trust in your directs, and patience in achieving whole-hierarchy change. but the thing is: steering isn’t *actually* achieved any other way. a syncing mechanism provides an “as if” model of steering, and if it were free and equally effective, that’d be fine. see the first point: it’s not just not free it’s quite expensive. you are paying a very great deal for the illusion of control. is it worth it?

point: verticality in team range, their free ability to operate in different technologies all up and down your code base, is wildly risky & inefficient only because we set things up that way.

  • first, the geeks on your teams already wrestle with at least a dozen advanced technologies every day. they are hardly incapable of navigating across these. it is in fact their whole job.
  • second, there are far cheaper ways to protect yourself against a noob breaking what has gone before than banning them from changing it. what if u had very high certainty that this could almost never happen? you can. it’s called TDD. and in no way coincidentally, in addition to the defensive benefit of TDD, there are *huge* advantages provided by it to your more experienced geeks AND to your noobs, entirely aside from risk-mitigation.

point: the whole reward/punish justification for sync points is foolish on a number of counts.

  • first: reward/punish? you are ignoring the last 100 years of research into human motivation, likely quite disastrously so.
  • second: if u seek to reward/punish team on grounds other than their productive health, you can do that any time you like anyway.
  • third: there is no reason whatsoever to believe that measuring sync-to-sync productivity can be in any standardized or made viable for cross-team comparison. we have a ton of info that suggests otherwise, and almost none that backs this notion.
  • fourth, same-team different sync-period comparisons by numbers are almost as bad. different teams wrestle with widely different degrees of difficulty from one sync period to the next. dead-ends abound in our trade, as do false starts, as do even key individuals’ lives.
  • fifth: interrupting flow is itself usually a punishment, as is evaluation from people who are so far above you they have to evaluate you based on numbers that don’t capture your state.

i’ll say this again, please memorize it now: there are only two ways to assess the health of a software team just two: live with the team. trust someone who lives with the team. that’s it. that’s all you got. if you can’t do one of those two things, you can’t assess their health.

point: your longer term plans don’t work very well at all now, with all those sync points. how much worse could they actually be? remember, you are *paying* for that sync, heavily.

further point: using sync-periods as buckets is a whole category of foolishness separate from all the rest. it ignores every single thing we’ve learned about the real world of software development for fifty years. it is just a staggeringly costly and hurtful practical joke.

so? lose it. forget about sync points. they cost a fortune, they help little, they often hurt a lot. focus on building unsynced systems that free intelligent trustworthy motivated people to do their best work. oddly enough, they will.

Desiderata: On Motives

so. this is hard for me to approach. the circumstance of my radicalism began when i was but 5 years old.

at age seven, under pressure, i became aware that some adults were dumb-asses. by the sixth grade, age twelve, i saw most things around me lies. i encountered people i thot were good and just behaving not good and not just. i was fully radicalized then.

around that time i stumbled upon the poem “desiderata”. it was a popular poster, and i papered my walls with posters. and, in poster form, it was claimed to be some ancient anonymous text, cited to some boston church — coincidentally i’m in boston tonight, but not at a church. in fact, it was written in 1927 by max ehrmann. i know nought of ehrmann other than the poem.

in conversation just now the line i regard as central came up. and — this is my 58th birthday, so some 40+ years on — i went back to the original. and i read it. and. and, it entirely recapitulates every good day of my life. i say this frankly embarrassed.

what, seriously, this long-forgotten poem, written by an unknown, printed on a poster by some hooker, pinned to my twelve-year-old’s wall with pins i bought myself from mowing lawns, 75 a year, ten bucks for me, the rest for the family kitty?

inebriation being what it is, and me being what i am… yes. yes, this poem still captures almost entirely what i do and who i am. i recite it to you now. further tweets are the poem, until i advise otherwise.

Go placidly amid the noise and haste, and remember what peace there may be in silence. As far as possible without surrender be on good terms with all persons.

Speak your truth quietly and clearly; and listen to others, even the dull and the ignorant; they too have their story.

Avoid loud and aggressive persons, they are vexations to the spirit. If you compare yourself with others,

you may become vain and bitter; for always there will be greater and lesser persons than yourself. Enjoy your achievements as well as your plans.

Keep interested in your own career, however humble; it is a real possession in the changing fortunes of time.

Exercise caution in your business affairs; for the world is full of trickery. But let this not blind you to what virtue there is; many persons strive for high ideals; and everywhere life is full of heroism.

Be yourself. Especially, do not feign affection. Neither be cynical about love; for in the face of all aridity and disenchantment it is as perennial as the grass.

Take kindly the counsel of the years, gracefully surrendering the things of youth. Nurture strength of spirit to shield you in sudden misfortune. But do not distress yourself with dark imaginings.

Many fears are born of fatigue and loneliness. Beyond a wholesome discipline, be gentle with yourself.

You are a child of the universe, no less than the trees and the stars; you have a right to be here. And whether or not it is clear to you, no doubt the universe is unfolding as it should.

Therefore be at peace with God, whatever you conceive Him to be, and whatever your labors and aspirations, in the noisy confusion of life keep peace with your soul.

With all its sham, drudgery, and broken dreams, it is still a beautiful world. Be cheerful. Strive to be happy.

(me again).

what i have tweeted is very possibly a copyright violation. i’m sure, in that case, to receive stern letters. yeah yeah. i’ve been kicked outta better bars than this, believe me. when some angry person tells me they have to read the poem on the ad-riddled site, i will forward it on to you.

meanwhile, tho. meanwhile. u know i was just 12, right?

alex harms and i have an expression, we use it to express our sympathy for people who are fucking up. “well, she’s just a boy, right?” it’s our way to remind us that we all got here without knowing what to do, and formulate what we can. cc @onealexharms

i stand before you fairly astonished. there is no part of max ehrmann’s poem i would wish to demure. i have spent my life on it i am glad to have done so.