Showing posts with label business. Show all posts
Showing posts with label business. Show all posts

Sunday, February 4, 2024

The Cost of (Technical Debt in) Doing Business


Ten and a half years ago, I wrote an article on technical debt strategies.  It was one of my most commented-on posts, and even got its own discussion on Reddit.  The point wasn’t to explain what technical debt was, but I did so (briefly) anyway, near the top:

In software development, there is always a tension between two opposing forces: the desire to do it fast, and the desire to do it right.  ...  If you do it right, then, later, when you want to extend it, or modify it, or use it as a jumping off point for branching out in a whole new direction ..., you can do so easily, with a solid foundation as a base.  The downside is that it will take longer.  If you do it fast, you get results faster, which means you can serve a customer’s needs before they change, fill a window of opportunity before it closes, or perhaps even beat your competitors to the market with your offering.  But when you have to modify it later (which you will), it will end up taking even more time to clean things up than if you’d just done it right in the first place.

You can see why we often call this “technical debt.” You’re saving time now, but you’ll have to “pay it back” later, and the amount of extra time it takes is like the interest.  Primarily, we software people invented this analogy because it makes good sense to business people.  ...

And I still say it’s a good definition, despite the snarky commenter who said it was “actually a definition of bad coding practices.” If you want a more complete definition—and some interesting history—you can find that on the Internet, though I’ll maintain that it’s not a better defition ... just more detailed.  Other Internet articles can explain even better than I could how the technical debt concept (more of a metaphor, really) neatly parallels the concept of financial debt, but, again: the analogy I used to follow the quote above is perfectly adequate for grasping the concept.  If you have a business, and you need a piece of equipment that costs $1,000, but you don’t have that much in the bank, you have two choices: you either wait until you do have that much in the bank, or you borrow some money and buy the thing now.  In the first case, you end up debt-free, but you’re paying what in business circles is called “opportunity cost”: if you lose money (e.g. to your competitors) because you couldn’t use that equipment while you were saving up the money, that’s the opportunity cost.  Contrariwise, if you borrow the money to save the opportunity cost, you’re paying interest, which is what we call in business circles actual cost—i.e., cash.

In fact, the concept of “opportunity cost” is a perfect companion to that of technical debt.  In both cases, you’re not talking about “real” money, in the sense of dollars you can count, but you are talking about real financial consequences, even if they can be hard to measure exactly.  And the point of them is the same: to turn something that’s a bit abstract and hard to grasp into financial terms, which businesspeople are really good at understanding.  If I had heard someone tell me that some business people were starting to think that opportunity costs were bullshit made up by other people to get them to do things they didn’t want to do, I would think that was crazy talk.

And, yet ... that’s exactly what I just recently heard said about technical debt.  That business folks weren’t taking it seriously any more because they thought it was just this made up thing to get them to take software maintenance seriously.  Which ... well, of course it is.  Just like opportunity cost is a made up thing to get people to take seriously the idea that waiting has consequences.  That doesn’t make the consequences less real, though; the fact that someone made it up at some point is true of everything in our society.  The idea of “running a business” was made up at some point, as was the title of “CEO,” as was the concept of “management” and the practice of “accounting.” But no one questions that these things are real, because, you know, they are.  And technical debt is real as well.  Trust me, I’ve been in software development for over half my life now: it’s very real.  Doing things fast (most often in order to avoid paying “opportunity costs”) is the choice most often made by the business side, and to be fair there are often really good reasons for choosing that.  But the costs are quite real, and quite often painful down the road.  Pointing out that someone had to invent a phrase for it doesn’t make it go away.

The thing that really frustrates me about this apparently growing attitude is that we (technical people, I mean—the term was invented by the same guy who invented agile programming) invented this stupid term so the business people would take the problem seriously.  Ward Cunningham, bless his soul, came up with the perfect metaphor—technical debt is the interest you pay when you borrow time to pay off your opportunity costs—and now the business people are rejecting it as “made up”?  Perhaps this is the real difference between “opportunity cost” and “technical debt”: the former is what business people use to justify expenses to their accounting departments, while the latter is what the tech departmnent uses to justify expenses to the business people.  So when the business folks are the justifiers, the term makes total sense and we should all use it.  When they’re the justifiees, though ... well, then it’s all bullshit.

To be fair, though—which I am very much not inclined to be on this issue—I should point out several of the articles I’ve cited claim that this is all our fault.  The technical people, says one, overused the term and just applied it to all their problems.  Engineers, it says, say “technical debt” when they really just mean “bad code.” And of course code can be bad for a myriad of reasons: technical debt is a big one, but certainly not the only one.  It goes on to lament:

When businesspeople don’t want to grant a “tech debt week” because they saw with their own eyeballs that the last one improved the team’s capacity zero percent, how can we expect them to grant us another one with alacrity?

Well, I’m not buying that.  If a business person says to accounting, “I’m going to borrow money to buy this thing,” and accounting responds, “don’t do that! it will cost us a million dollars in interest!” then I’m pretty sure there’s going to be some fact-checking going on.  What I’m saying is, the business folks have to bear some of the responsibility for not bothering to take the time to understand exactly what technical debt is being paid off in a “tech debt week” and what the benefits will be.  Also, what are the chances that the team will achieve their goals?  Because sometimes ripping out the kitchen cabinets and replacing them with ones where the doors aren’t falling off takes longer than the contractor’s initial estimate.  This is all very standard stuff that any businessperson worth their salt would consider when buying a physical item or hiring for a particular job.  And, if the business side asks, and the tech side has to explain themselves, then they’ll rapidly become disabused of the notion of throwing all their problem code into the “tech debt” bucket.

Another post offers the tech side this advice:

Instead, say: this is how long it will take to do.

Not “if we rush we could probably do it in...”; no, if you say that, then why are you not rushing now? Do you not care what the business wants? Do you not have ‘skin in the game’?

Say: This is how long it will take, we estimate. If you want it faster, we can cut some features.

Again, this is not how things work in the real world.  When the plumber comes by and says, “I’ll need to replace this pipe, because it has a hole in it.  It’ll take about 4 hours to get it done.  Or, I could do a quick patch job on it and get it done in an hour.” you don’t respond, “Why aren’t you rushing now?” You ask what the consequences will be for that rush job.  Is it going to keep leaking, just not as bad? is it going to stop the leak completely but only for a few days, and then you’ll just have to call the plumber back again?  There’s obviously a reason why they’re offering you the option of doing it right vs doing it fast, and you will certainly want to hear that reason.  But under no circumstances is the fast option “cutting some features”: it’s delivering the same features with substandard quality.  That is the entire point of technical debt.

But my favorite one is this, from the very first article I referenced:

In an impassioned post, a long-time software development consultant, Uncle Bob writes “A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational. It’s always based on laziness and unprofessionalism and has no chance of paying off in the future. A mess is always a loss.”

This is such complete and utter horseshit that I’ve pre-emptively lost all respect for this “Uncle Bob” character, and I don’t even know who he is.  The fact of the matter is, sometimes you make the decision to do the quick patch job, because you really need that pipe to work for just a few more weeks, and the inevitable resulting mess—which, depending on the size and location of the pipe, might be prodigious indeed—is absolutely not the result of being lazy or unprofessional.  The customer (who is in this analogy the business side) understood and accepted the risk; the contractor (here representing the technical side) was neither lazy nor unprofessional: they did exactly what was asked of them, almost certainly over their strong objections, and definitely cannot be held responsible for the resulting water damage.  I have to believe Uncle Bob never had to pull an all-nighter trying to “just make it work” for the customer demo the next day.  A mess is not “always based on laziness and unprofessionalism”; a mess is, sometimes, just the best you could manage at the time.

So I suppose the business people will continue to crack the whip and the technical folks will continue to beg to be able to clean up their messes, and now they’ve even taken away the phrase we used to help them understand the urgency.  I don’t really blame the business people in my own company: they’re just responding to the zeitgeist.  And I’m still not buying this notion that I should blame the wider tech community—it’s 100% true that some engineers have doubtless misunderstood the proper use of the phrase, and that’s contributed to its being misused and consequently watered down.  But I find the parallel of “opportunity cost” very instructive: its challenges are similar, people often misunderstand its use and try to appropriate it for their own purposes.  But it continues to be useful (and to be used) anyway.  And I think that’s because its use benefits the business community, so they resist any abuse of it and hold onto it fiercely.  The concept of “technical debt,” on the other hand ... that, they have have little use for, so it’s fine if it falls into disuse and neglect.

Of course, one might argue that, by not understanding technical debt (and not devoting resources to pay it down), the end result is that the company has to spend more and more time to achieve the same results.  That’s time that businesses could be spending making customers happier by delivering more quickly, responding to competitive threats more nimbly, or breaking into new markets with innovative new features.  What I’m saying is, rejection of the concept of technical debt, in my opinion, has a real opportunity cost.









Sunday, July 16, 2023

Of Waterfalls, Pigs, and Red Red Tape

Once upon a time we used to develop software via something known as the “waterfall model.” When trying to envision this, don’t think about something like Angel Falls, where the water just falls off a cliff.  Picture instead something along the lines of Detian Falls in Vietnam: a series of steps as the water drops, level by level, to its final destination.  See, back in those olden times (which, honestly, were mostly before I got into the industry, though there was some residual inertia even in the mid-80s, when I came along), back then, as I say, the specifications (or “specs”) were developed by one team, who then passed them along to the design team, who designed the whole system in a very abstract way, and then passed it along to the programming team, who did all the hard coding work, and then passed it along to the QA team, who verified that the functionality matched the original specs, and then they passed it on the customer and then it’s done.  The primarily analogy to a waterfall for this development model is that the water only flows one way: for the real-world waterfall, that’s due to gravity, and for the waterfall model, it’s because going backwards—“upstream,” if you will—is expensive.  You really want to get each phase just perfect, because if you find a mistake, you essentially have to start over ... and that costs the company money.  Sometimes, with this model, starting over was so expensive that they just didn’t.  The greatest stories of software development debacle were due to the sunk cost fallacy: too expensive to try get back up to the top of the waterfall, so we just gotta make due with whatever horror show we’ve ended up with.

So throughout the 80s and 90s software developers started saying there had to be a better way.  In 1986 the “spiral model” was proposed: it was built into the system that, instead of planning out the whole system at the beginning, you’d spec out just an initial prototype, then design that, code it, test, then go back to the spec stage and tack on more features.  Starting over was no longer a bug, but a feature.  Instead of losing a bunch of money because we had to start everything from scratch, we were only starting the next thing from scratch ... and, if we needed to tweak some stuff from the first iteration, well, we already had the mechanisms in place for specifying, desiging, coding, and testing.  Those phases were in our past, true: but they were also in our future.

Of course, the spiral model is a very abstract concept.  How do you actually implement such a thing?  That is, what are the actual processes that you put into place to make sure the company and its employees follow the model and achieve the goals of iterative design?  For that, we needed to move beyond models and into methodologies.  Enter Agile.

Agile software development practices, usually just referred to as “Agile,” were a way to concretize the spiral model abstraction.  Sometimes they would propose tweaks to the model, sure, but the main thing was, no going back to waterfall.  And, to distance themselves from those crusty old waterfall methodologies—many of which were by this point formalized as standards, such as the DOD’s 2167A—they all had cool new names: RAD (“Rapid Application Development”) and Scrum and Crystal Clear and Extreme Programming (if you didn’t just hear a Bill and Ted’s-style guitar lick, you’re doing it wrong).  This last one, usually abbreviated to “XP” (no relation to the Windows version) was not the first agile methodology to come along ... but it was the first one I was ever exposed to, and they say you never forget your first.

Kent Beck, author of “Extreme Programming Explained,” presented to me a perspective that literally changed my (software development) life.  He pointed out that, in order for the waterfall model to work, you have to be able to predict the future.  The whole thing is predicated on predicting what problems will happen, anticipating them, and building them into the plan.  If you fail to predict something, then everything falls apart.  Except ... humans really suck at predicting the future.  When we say “predict,” what we really mean is “guess.” And we usually guess wrong.  As Kent so succinctly put it:

The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.

Stop trying to keep change from happening: it’s a fool’s errand.  Rather, create a better methodology which says “yeah, things change: so what? we got that covered.”

Agile is all about being flexible.  Hell, the reason it’s called “agile” is because the old waterfall methodologies were ponderous and slow to course-correct.  It’s common for business people to talk about agility in terms of responding to changes in the market: the creators of the Agile Manifesto (one of whom was Beck himself) wanted to capitalize on that perception.  Our development practices can make your company more agile, and that makes you quicker to respond, and that helps you beat your competitors.

And yet ... it’s kind of strange that we need all these procedures and guideliness and principles and a whole friggin’ manifesto to perform something for which the entire purpose is to be flexible.  The thing I never liked about XP, despite all its merits (and the aforementioned life-changing-ness), was that it had all these notes about how, if you’re not following every single rule, then you’re not “doing” XP.  You’re just playing at it.  I always found that inherent dichotomy cognitively dissonant: so I have to do things exactly according to these rules so that I can break the rules? I have rigidly fit into the straitjacket so that I can have the flexibility to move freely? I have to precisely walk the straight line so that I have the freedom to jump in any direction?  Surely you see the contradiction.

And XP is certainly not alone in this strange philosophy.  I’m not sure we can claim any of the Agile methodologies to have “won,” but in my experience Scrum has made the most extensive inroads into corporate culture.  And it is chock full of prescriptive little strictures: mandatory stand-up meetings with strict time limits and precisely defined cycles called “sprints” and detailed reporting pathways between developers and business owners.  Maybe all this red tape is why business people have embraced it more than the other Agile practices.  But it presents a weird, oxymoronic message to the developers: we want to you to be free, we want you have flexibility, but you have to all these things, just so.  And sometimes the business owners can get very upset if you question this.  Because they’ve been trained, you see?  They’ve taken courses in “how to do Agile” and “how to run Scrum” and all that, and (of course) all those courses stressed that you have to do everything perfectly or else it will all fall apart, so as soon as the developer suggests that maybe we should change this one thing because it’s actually making our lives harder ... well, it won’t be pretty, let me tell you.

One of things I always liked about Scrum was that they made clear the difference between involvement vs commitment.  The traditional explanation for this is via the fable of the pig and the chicken.  Now, these days Agile folks will tell you not to use that story to explain things any more.  The first reason they cite is that people will take offense: calling someone a pig implies they’re greedy, or dirty; calling them a chicken implies that they’re cowardly.  These are, of course, human metaphors that we’ve placed on those particular animals, and also they have nothing to do with the actual story.  But people won’t hear the message, they point out, if they’re hung up on the words used to deliver it.  I would probably say that people will look to any excuse to get offended, especially if it gets them out of following rules, but I’m a bit more of a cynic.

The story points out that, in the context of preparing a breakfast of eggs and bacon, the chicken is involved, but the pig is committed.  This is a very simple concept to grasp, and the analogy illustrates it perfectly, but, yes, yes: let us not offend anyone.  I would be fine if this first reason were the only reason that modern Agile advocates had dropped the pig and chicken story: that would just mean that they had replaced it with a different analogy that perhaps involved more noble animals, or fruits, or something.  But, no: they’ve started to question the whole concept.  See, the original point of pigs and chickens was to point out to the business people that it wasn’t particularly fair (or, you know, sensible) for them to set deadlines for how long something would take.  They weren’t the ones doing it.  The developers have to actually accomplish the thing, and they know how long it should take (even if they’re bad at estimating that for other reasons, which are happily addressed by other Agile practices).  The business owners are involved, but the developers are committed.  This not only stresses to the business folks that they don’t get to say how long something takes, but it also stresses to the developers that, once they say how long it will take, they’ve made a commitment to getting it done in that timeframe.  These are all good things.

But not so, says the Updated Scrum Guide.  Those poor business people shouldn’t be made to feel like they can’t dictate timelines.  “In some cases these people were key project sponsors or critical system matter experts. These are individuals who, while possibly needing some education and guidance from a Scrum Master, can be critical to the success of a project.” If you’re not familiar with how to translate business bullshit back into English, this means “we want the business people to feel important, and they don’t like it when we try to put restrictions on them, and if I say it this way it’ll make you think that you developers are actually gaining something, rather than that we’re just caving in and letting the business people run roughshod over all we’ve built.” The thing I always liked about the Agile practices was that they were pretty balanced in terms of business vs development.  They said to the developers “we want you to feel respected and like your creativity is valued, and you should be in control of what you produce and the quality of your work.” But they also said to the business side “we want you to feel respected and like your market acumen is valued, and you should be in control of what gets produced and how viable it is as a product.” See? everybody is respected equally.  When you start breaking down that balance, bad things happen.

And maybe business people feel empowered to just set some processes up because it sounds good, or because it looks official, or maybe, like most other humans in workplaces, they just like telling other people what to do.  And maybe those processes actually slow things down instead of making them more efficient.  And maybe the developers feel like they can’t speak up any more—it’s no longer the case that they’re the ones who are committed because everyone’s committed now—or maybe they do speak up but they’re ignored because setting up workflow processes ... that’s above your paygrade, don’t you know.  And gradually, slowly, everything goes back to the bad old ways when we spent way more time talking about getting things done than actually doing things.

Doesn’t feel very agile, does it?









Sunday, January 15, 2023

OGL Doomscrolling

I’ve never been particularly susceptible to doomscrolling.  I didn’t do it during the height of the pandemic, nor on January 6th, nor even during the run up to (and aftermath of) Trump’s election.  I didn’t do it during the most intense times of the Black Lives Matter protests, nor during the most heinous parts of Russia’s invasion of Ukraine.  The closest I ever really got was an obsession with TV news shortly after 9/11, but that was technically before doomscrolling was a thing (although really it was the same impulse).  But, overall, I was starting to think I was immune to the syndrome.

And then Hasbro, the parent company of Wizards of the Coast (or WotC)—the company that makes D&D—started fucking with my game.

Now, on the one hand I suppose it makes sense that this thing, which is more likely to affect me personally than any of that other stuff (maybe even more so than COVID), was the thing that finally caught me in its web.  But that’s sort of a shallow assessment, and I would at least hope that there’s a better explanation than that.  After some introspection, I think I’ve put my finger on it: none of that other stuff really surprised me.  Anyone who was surprised that Putin would invade a country just hasn’t been paying attention, and anyone who was surprised that cops were killing black people is beyond clueless.  The US government wasn’t prepared to deal with a major health crisis? yeah, some “breaking news” there.  Corporations are using the pandemic to gouge us for more money? well, duh: it’s what they do.  As for Trump, I can’t say which is less surprising: that a politician would be a compulsive liar, or that a rich white guy would be self-absorbed and unscrupulous.

But this ... this actually caught me off guard.  I never thought that this could happen.

And that’s primarily because it already happened once before. See, what Hasbro is doing is trying to screw with the Open Gaming License (OGL), which was invented for the third edition of the game (3e), and tries to do for tabletop roleplaying games (TTRPGs) what open source licenses did for the software industry.  Both 3e and 5e use the OGL, but 4e did not.  What happened?  Well, presumably, some dick executives at Hasbro decided that it sucked that other people were making money off D&D and decided to create a new version that wouldn’t use the OGL (I actually cover this is some detail in my discussion of what Pathfinder is).  And it bombed.  See, 3e made D&D the biggest TTRPG in the market—by a huge factor.  Other TTRPGs were, in those days, like browsers other than Chrome: sure, they exist, but the only people you know who use them are hardcore nerds.  4e killed all that, and other TTRPGs began to equal—or even overtake—D&D.  And it’s obviously an oversimplification to claim that moving away from the OGL was responsible for that ... but it’s hard to ignore it as a factor as well.

Especially when you factor in that 5e brought it back.  Basically, WotC said, “hey, guys, we know we screwed up, but now there’s a new version of the game, and it will use the OGL again ... please come back to us.” And it worked.  Oh, sure: once again it’s too neat and tidy to lay the massive success of D&D in recent years at the feet of re-embracing the OGL.  But, also once again, it’s hard to ignore that factor.  So it seems like the company learned their lesson, and now everything is good ... right?

Except corporate executives come and go, and often institutional memories are amnesiac.  Those who cannot remember the past are condemned to repeat it, warns George Santayana, and that’s exactly what’s happened now.  Thus, doomscrolling.


Well, today is my last allotted day to obsessively hit the refresh button to get the latest news on this topic, so perhaps I can declare it not a complete waste of effort by giving you, dear reader, a few links which can hopefully tell the story in a cogent, coherent manner.  I tried to focus on shorter articles and videos to make it quicker to get through, but there’s no getting around that this is a big topic, so don’t dive in unless you’re willing to spend some time on it.  But, for all that, I think it’s a really fascinating topic, with business aspects, legal aspects, issues of creative vs capitalist, and feats of journalism.  If you do have the time, it might just be worth it to take a look at this particular controversy.  And, even if you’re not into TTRPGs, considering the fact that the blockbuster D&D movie is scheduled for March, and a new D&D TV show was just announced, it’s possible that the fallout could impact a lot more folks than that, if only tangentially.

For each link below, I’ve indicated what format the media is in, and what expertise the author is bringing to the table.  I’ve tried to arrange things into an order that makes the story easier to follow (which is decidedly not chronological order of these things being published), and add a brief bit of commentary as to what I think the value of each is.  This list is highly curated, based on my own opinions; I tried to save you from going through a lot of the dreck that I did during my doomscrolling spree, but that inherently means that my bias about what to include and what to omit is on full display, so take with as many grains of salt as you feel appropriate.  Some of these I’ve marked “informative,” if they’re primarily to get raw data; some I’ve marked “entertaining,” if the authors have added a bit of flair to make the new go down more easily; and some I’ve marked “emotional,” if the authors are letting their feelings show as to how much this is impacting their lives and livelihoods.

I’ve explained most of the acronyms above; “3PP” means third-party publisher (i.e. someone who is not WotC or the consumer who is publishing D&D-related material).  The fate of the 3PPs are the main thing that’s in doubt with this move from Hasbro / WotC.  It’s also fair to note (as some of the folks below do) that, when we demonize the “company,” we need to be careful to disinguish the sleazy executives from the rank-and-file employees of WotC (and its subsidiaries, like D&D Beyond), who are really just trying to get along, and many of whom don’t agree with the policies of the “company” at all (and several of whom are, apparently, responsible for many of the leaks that are fueling the fire, precisely because they can’t stand idly by).


What the hell is all this about anyway?

  • Best overall summary: (video) Mark “Sherlock” Hulmes (D&D streamer); emotional.  The first 13 minutes here are the best breakdown of almost every salient event that I’ve heard so far.

  • Best summary of the situation pre-leak: (video) Profesor Dungeon Master (D&D streamer and third-party publisher); informative.  The first 4 minutes here are a very concise window on the situation up to the point where the leak happened (the leak was just a rumour at this point; it became official upon publication of the Gizmodo article—see below).  After that, the Prof goes on to make some fairly cogent commentary and predictions, but a lot of it was invalidated by later events.

Was the original OGL useful?

  • Negative: (text) Cory Doctorow (author); informative.  Some people say the original OGL was useless or even harmful.
  • Positive: (video) Roll of Law (lawyer); informative.  Others counter that this is too simplistic a view.

The business issues driving this

  • Early predictions: Flute’s Loot (D&D streamer); informative.  Really, Flute is just collecting words of wisdom here from Matt Colville (founder of MCDM), but, since he’s done us the kindness of picking out just the good bits, we may as well take advantage.  (And he does add some useful commentary.)
  • Assessment of the factors leading up to this situation: (video) Ryan Dancey (former VP at WotC and co-author of the original OGL); informative.  Nice short clip from a much longer discussion with the Roll for Combat folks (who were one of the third-party publishers involved in the leak) which explains very cogently the business side of things from someone with inside knowledge.

  • What WotC should have done to address “undermonetization”: (video) Tulok the Barbarian (D&D streamer); entertaining.  This is probably about as pro-Hasbro as it gets (spoiler: still not very pro-Hasbro).  While this came out before the ORC license annoucement (below) and way before WotC’s response (even further below), it is still the absolute best (and funniest) assessment of what WotC / Hasbro could have done—still could do, for that matter—to address their concerns that D&D is “undermonetized” without pissing off their customer base.

What’s bad about the (proposed) new license?

  • The original leak: (text) Linda Codega for Gizmodo (journalist); informative.  This is what kicked off the controversy.
  • Why it’s legally bad: (video) The Rules Lawyer (lawyer and D&D streamer); informative.  A good summary of the issues from a legal standpoint.

  • Why fans are outraged: (video) DnD Shorts (D&D streamer and third-party publisher); entertaining.  Anti-Hasbro biased, obviously, but really encapsulates why people are freaking out.

Reactions from the community

  • A typical 3PP reaction: (video) The Dungeon Coach (D&D streamer and third-party publisher); emotional.  I could list literally dozens of videos just like this one, but I think DC is honest and raw and lays it out straight.
  • The #OpenDND movement: (video) The ArchCast (D&D streamer); informative.  A decent summary of the situation post-OpenDND but pre Paizo.
  • The ORC license: (text) Charlie Hall for Polygon (journalist); informative.  Paizo are the makers of Pathfinder, you may recall, and are severely impacted by all this since Pathfinder (or at least the first version of it) is completely dependent on the original OGL.  This article is a nice summary of Paizo’s annoucement of the new Open RPG Creative (or “ORC”) license, and it includes a link to the full announcement if you want to read that.

  • Community reaction to the ORC license: (video) No Nat 1s (D&D streamer); entertaining.  I don’t love this guy in general, but his joy at the Paizo annoucement (just above) is kind of infectious.

The campaign to send WotC a financial message

  • A typical plea on Twitter: (tweet) Ginny Di (D&D stremer); interesting.  Ginny Di is a major influencer in the D&D space.  Note that she’s retweeting something from DnD Shorts (see above), but most people feel it was her signing on that really made this go viral.
  • A typical plea on YouTube: (video) Indestructoboy (third-party publisher); interesting.  Reasoned and rational.

  • The end result: (video) Tenkar’s Tavern (D&D streamer); informative.  Not necessarly the best on this topic, but probably the most compact.

WotC’s response

  • What it is and why it’s bad: (video) DnD Shorts (D&D streamer and third-party publisher); entertaining.  The only person I’m linking to more than once, Will from DnD Shorts is definitely very anti-Hasbro, but he’s just so damned articulate and simultaneously so damned entertaining that I can’t not point you at his videos.  This video contains the entire text of WotC’s response.

  • Why people find it offensive: (video) Dungeons & Discourse (UK legal professional* and wargaming streamer); entertaining.  Originally an anti-corporate voice in the wargaming hobby space,** this creator originally published videos under Discourse Miniatures.  She actually just started this new channel focussing on TTRPGs specifically because of this OGL debacle.  She’s informed, articulate, funny, and I adore her accent.***  (I actually just signed up for her Patreon.)


So that’s it; pretty much the whole story.  There are more details out there, but don’t get sucked in like I did.  It’s not worth it.

And maybe now I’ve learned that even something this massively stupid shouldn’t surprise me.  Hopefully that’s armor against the next crazy-ass thing that might tempt me into wasting my life reading about shit that’s just going to depress me anyway.  One can always hope.



__________

* The UK has a few different professions which are licensed to practice law, and I don’t know exactly which one she is.

** Remember that D&D actually grew out of wargaming, so it’s definitely related.

*** Northern Ireland, perhaps?











Sunday, April 3, 2022

The Pros and Cons of Working from Home

[This is ostensibly a short post week, so I was going to do a quick discussion on a random topic, but it came out a good deal longer than I expected.  So, lucky you: you get two long posts in a row.]

I was speaking to a friend of mine earlier today; he has a job in the government, and I guess our government (or at least some parts of it) are not really into the whole remote working thing any more.  I’ve also been hearing some stories lately about big companies like Google who are apparently now telling employees that they have to return to the office.

But here’s what I don’t get:  I also heard a bunch of stories about how companies are having trouble retaining employee.  This is not one of those things where maybe a few news outlets are trying to sensationalize something: this is something that people are doing studies on, and it even has a name (and corresponding Wikipedia article): the Great Resignation.

Now, even Wikipedia will tell you that part of the reason for this—and not that you needed anyone to tell you, because: duh, of course it is—is that many people enjoyed working from home.  They enjoyed not having the vicious commute (some people are saving 2 – 4 hours a day, five days a week ... that’s 10 – 20 hours per week of their life they’re getting back), they enjoyed being able to work in whatever environment and clothes and furniture they find most comfortable, they enjoyed the freedom of not having to spend all that extra time in the bathroom making themselves “presentable” (assuming no Zoom meetings that day, of course).  Sure, many folks ended up feeling isolated and disconnected from their companies and their coworkers, but I personally believe there were just as many people who were appreciative of the chance to spend time with their families during times when they normally couldn’t.  Being quarantined with your family with no job surely must have been a trying experience; being quarantined doing remote work with no family must have been even worse.  But for those of us fortunate enough to have both a job and a family, there have been perks.  When I got tired of my job, I could go see what my kids were doing, and maybe spend a few minutes just chatting with them, or, hell: go out in the yard and do things with them for a bit.  When I got tired of my family, I could just say “gee, guys: I gotta get some work done now” and go in my room and shut the door.  It was, in many ways, the best of both worlds.

And so many companies had to figure out how to make an all remote workforce work.  And they did.  And I bet that my company was not entirely alone in discovering that an all remote workforce has its advantages: you don’t have to pay for office space, and suddenly your candidate pool expands exponentially.  No longer are you limited to candidates who live in your area, or candidates willing to relocate ... you can hire anyone. Anyone in the country, at least, and maybe even anyone in the world.  There are a few challenges dealing with a bunch of different tax jurisdictions, but I would guess that, at this point, my smallish company (around 200 employees, more or less) has workers in at least a dozen different states, and that number keeps growing.

So, given all that, what crazy people are going to demand that people come into the office if they don’t want to?  They’ve already been forced to prove that they don’t have any good reason to do so—they’re basically just being dicks about it at this point, which was really always true, but now it’s obvious to everyone.  And the Great Resignation means that job opportunities abound, so it’s not like the employees are stuck with you whether they like it or not.  So, if you’re a corporate entity in 2022 telling employees that they “have to” come back to the office, I think you’d best be prepared for a healthy chunk of responses that are something like “oh, yeah? you sure about that?” And also a lot fewer employees.  For instance, I wouldn’t want to say that my friend is definitely looking for another job right about now ... but I’m guessing he’s not not looking either.

Another interesting topic we broached in our discussion that I hadn’t even considered: workplace drama went way down during the pandemic.  Office politics and scheming and backstabbing and so forth: turns out there’s a lot fewer opportunities for that sort of thing when your primary interface with your coworkers is, you know: the work.  I personally work in a place that never had very much of that anyhow, but that’s obviously the exception.  Most places I’ve worked are full of people who believe they live in a soap opera.  Some of them are just on power trips, but a lot of them are using their social manipulations skills to cover for not being very good at their jobs.  I bet a lot of those people struggled during the pandemic.  Of course they’re probably very happy to return to the office.  And, hey: if corporate America is going to get divided into those companies that embrace all-remote working and those that reject it, I’ll be super-happy to see all the assholes on the same side of that line where the only people they can fuck with is each other.  I’ll be over here on my side, living my best life.









Sunday, July 7, 2019

R.I.P. ThinkGeek


As many of you may know, ThinkGeek disappeared from the web this week ... you can still put the address into your web browser, but you’ll end up on GameStop’s site instead.  For the most part, it went quietly, without huge fanfare.  Some of us former employees “celebrated” this event the way we’d always done when someone left the company: we drowned our sorrows in tacos.  If you’ve seen a hashtag #TacosForTimmy—well, you probably haven’t, as it wasn’t trending worldwide or anything, but you can check it out on Instagram or Facebook.  But saying goodbye to TG was what that was all about.

I’ve mentioned before that I worked there, albeit briefly.  In fact, I once did a blog post talking about my time doing the Ask Timmy column.  Now, on the occasion of ThinkGeek’s (metaphorical) passing, someone suggested that I might be inclined to do one final Ask Timmy as a sort of eulogy.  I considered this quite seriously.  But the problem there is, Timmy is wise and clever and, most of all, he’s always nice.  I’m not sure that my own feelings on what ThinkGeek meant can be that restrained.  Truth be told, I have a little bit of bitterness about the whole thing, so let me get that out of my system first.

First, a bit of history.1  These 3 pals Willie, Jen, and Scott were running a small ISP, back in the days when there were such things as small ISPs, and they had an idea for a side business, selling geek T-shirts and electronic doodads from a separate website.  They enlisted one of their ISP empmloyees, Jon, to pitch in, and the original thinkgeek.com was born.  Shortly thereafter, it got slashdotted and the resulting traffic brought the servers down.  That’s when they knew that they had hit upon not just an idea that people would pay for: they were hungry for it.

It was the very late 90s, and the dot-com bubble had yet to burst ... although, even when it did, ThinkGeek survived.  Nowadays companies such as Nerdist and Geek & Sundry get a lot of (very deserved) credit for the proliferation of nerd culture ... but, don’t forget that ThinkGeek predated both by over a decade.  In fact, while we can always quibble over the details, I would contend that ThinkGeek was the original purveyor of “geek chic,” and that it was a really big part of why geek is now big business.  Which can only lead to the question: what happened?

So, here’s my theory, and you can take this with as much salt as you care to: I was sort of vaguely an insider, but only for a very brief period (about 3½ years out of ThinkGeek’s 20 year history).  So I’m speaking about 82.5% as an outsider, really.  Bear that in mind.

As part of one of my other series I’m working on, I’ve actually done a bit of historical research on TSR, the company that originally created D&D.  It’s a complex story, but I think I can sum it up pretty succinctly: it was started by a geek (Gary Gygax), then it started making money, then the business people came in and forced him out, then they nearly went bankrupt.  It was eventually bought, by the way, by Wizards of the Coast, which was started by a geek (Peter Adkison), then it started making money, then the business people came in and forced him out, and then they got bought by Hasbro.2  This is nothing new, of course: Netscape was also founded by a geek (Marc Andreesen), then it started to make money, then the business people (in this case AOL) came in and forced him out, and now it’s a dead browser.  Remember Slashdot, the catalyst of ThinkGeek’s early success?  Founded by a geek (Rob Malda), started making money, then the business people came in (the same corporate entities that would go on to buy ThinkGeek, coincidentally3) and forced him out and now I can’t name anyone who still goes to the site for their news.  Hell, this pattern goes all the way back to Nikola Tesla, if not further.4  And it’s still going on today: Chris Hardwick and Felicia Day seem to be gone from Nerdist and Geek & Sundry after their purchase by Legendary (and then repurchase by a Chinese conglomerate).  And, again, we can quibble over details—for instance, I’m sure some of those geeks would disagree with my characterization of them being “forced out.”  A number of them left pretty unwillingly, but several of them decided to move on all on their own ... and yet I find it hard to believe that any of them wouldn’t list “increasing corporatization” as a contributing factor to their exits.

And, amidst all of what seems to me to be a pattern so clear even a monkey could pick it out, there seems to be this meme that geeks are just terrible businesspeople.5  For instance, I just dug out an old podcast featuring two scholars who wrote books on Gygax, and they both agreed on his lack of business acumen.  And yet ... what was step two of that recipe?  Step 1 was the part where the geek starts a business because they have a product that they’re passionate about and they want to share it with the world.  Step 2 was the part where it started making money.  Because, let’s be crystal clear on this: the big corporations don’t want anything to do with you if you’re not making lots of money.  Oh, sure: they always think they can make more money than you could on your own ... and yet they always seem to be wrong, in the end.  Probably just coincidence.

Now, part of the reason the “good” businesspeople never take any of the blame for the eventual (entirely predictable) failure is that such failures inevitably take a long time.  And, in the meantime, there are still wonderful, creative people working really hard to produce good things despite the terrible ideas the people who are ostensibly good at business are forcing on them.  TSR, for instance, produced some of their most iconic products and settings after Gygax left.  And ThinkGeek was certainly no exception to this rule.  Some utterly fantastic products were produced well after ThinkGeek was bought, and some utterly fantastic people worked there, some of whom I’ve had the pleasure of meeting despite never having had the chance to call them my coworkers.  I would never want to diminish any of the contributions of these folks.  But I have to say the downward spiral always seemed inevitable to me, and it was one of the reaons I left when I did.

ThinkGeek was bought by Andover.net, and Andover was bought by VA Linux, which changed its name to VA Software, which changed its name to SourceForge, which changed its name to Geeknet, which was almost bought by Hot Topic, but then was bought instead by GameStop.  And now it is gone.  And geeks everywhere are sad.  Honestly, I feel like it’s not so much that geeks are bad businesspeople as it is that businesspeople are bad geeks.  See, geeks know what geeks want to buy—I can’t believe that I have to say this like it’s some sort of profound statement when in actuality it’s sort of self-obvious.  Businesspeople, apparently, do not know what geeks want to buy, or how to treat them well.  They always seem to have these grand plans, and of course they know better than everyone else how to make money ... except they kinda don’t.  Any entry-level course on business will tell you that one of the most important concepts in order to be successful is to understand your market segment.  And yet, corporate overlords, again and again, think they know better and push out the people who know what they’re doing—the people who made the companies successful in the first place.  Then they just sort of flounder around dopily until they realize they have no clue what they’re doing and they either shut it all down or sell it to some other corporate sucker and congratulate themselves on a job well done.

Jon left first, and then Scott, and then Jen, and finally Willie, in 2013.  I wasn’t there for the last 3, so I can’t say for sure, but I deeply suspect that at least some of them didn’t go willingly.  I was there when Jon left, and so I can tell you for a fact that he was pushed out, in the sense that the corporate people running the place made it so miserable for him that he finally just gave up.  I know this because I was asked to participate in it.  I refused, and so I was next on the list of “how toxic do we have to make the environment before he leaves?”  The answer was, not too much more so.  I left ThinkGeek in 2007, after a really dumb argument with the manager who was the extension of our corporate rulers,6 and I moved here to California.  Where I am really really happy, and my family is very happy, and I have a pool with a jacuzzi and all that, so it’s not like I’m complaining.

Except ...

Except that, despite the fact that it comprises only around 10% of my career as a software guy, my short tenure at ThinkGeek was one of the best experiences of my life.  I had just come off 13 years of running my own business, which I only did because I was convinced that it was literally the only way to have a company that was a fun, respectful place to work.  I probably would have kept on doing that forever, except that the dot-com crash indirectly borked me by flooding the market with all those “programmers” who had gotten into the business during the bubble and now were willing to work for cheap.  They couldn’t match our quality, of course, but, at the point at which a company can afford to hire 3 or 4 such schmucks for what they used to pay us, they just figured they could make up the quality with quantity.  And I was forced to go work for someone else again, and I figured I would hate it.

Instead, I met Jon and Andy (who, despite being inherited from Andover was not a corporate shill, but rather one of the best bosses I’ve ever had) in a restaurant / pub, where we had some dinner and drank some beer and talked about whether I’d be a good fit for ThinkGeek.  All the cultural stuff they talked about sounded awesome—too good to be true, if I’m honest—and it was just left for me to have a more technical 1-on-1 interview with Jon.  Should I come by early in the morning some time?  I asked this with some trepidation, as I kind of suck at mornings, but I knew that was what was expected in the corporate world.  There were chuckles.  A lot of the ThinkGeek crew aren’t morning people, I was told, and Jon certainly isn’t.  Come by in the evening after the work day is mostly done.  I breathed yet another sigh of relief.  When I pulled up to the front door (it was, in those days, a small office on the backside of an office park about the size of a strip mall), Jon happened to be outside smoking.  I put on my emergency flip-flops, got out of the car and smoked with him, mostly in silence.  Then he said, let’s go in and talk, and we walked through the door, and the first thing he did was take his shoes off, and I was pretty much in love.  In love with the company, in love with the philosophy, in love with the dogs at the office and the cool toys that were always lying around and the loud music that we played for “inspiration” and the company videogame consoles and what passed for “meetings” which was mostly us sitting around a table and acting goofy while coming up with cool ideas, but mostly in love with the people.  I’ve written plenty about my love for Willie, so I won’t repeat it here, but I loved all those guys.  Jen, who was the first person I ever met who called themselves a “web designer” that wasn’t a pretentious bastard but rather a smart, thoughtful person who had style and understood how the web really worked.  Scott, who was one of the most down-to-earth guys I’ve ever had the pleasure to work with and was just a joy to be around.  JenVon, who was one of those no-nonsense types who always knew exactly what was going on and how to do things more efficiently, and yet still was super-fun to hang out with.  And of course my fellow code monkeys: Jon, who knew how to put his head down and just get shit done, who was often quiet but had a sly wit, and absolutely magnificent taste in music;7 and his eventual replacement Jacob, who was so earnest and genuine and probably cared more about the people who ultimately benefitted from the website (a.k.a. our customers) than anyone else I’ve had the pleasure to work with.  And all the rest of my ThinkGeek peeps like Andrea and JennK and even the people who I never met until much later like Kate, and many more: I love you all, guys.  You changed my life for the better.

Which, you know, sounds ... well, to call it “hyperbolic” probably seems like an understatement.  It probably sounds like overblown bullshit to many of you.  But it really is difficult to convey how impactful this one job was for me, and (I’m pretty sure) for just about everyone who worked there.  Oh, sure: we all bitched about corporate this or that, and we fought sometimes (as all work siblings do), and we had some bad days.  But we all respected each other, and we not only tried to have fun, we mostly succeeded.  More than that: we believed it was part of our job to have fun.  Not just work hard all day and play hard all night, but actually play while we worked, so that just about every day you would wake up and go, yay! I get to go to work today!  Most jobs aren’t like that ... most jobs don’t even come close.  But I got to do that for 3½ years, and I will always be grateful to the people that made that happen, and just a touch bitter about the people who made it go away.

So perhaps one day I’ll readopt the calm, soothing, wise voice of Timmy the Monkey and do a more proper eulogy: you know, the kind where you only say nice things about the deceased and ignore any faults they might have had.  But this week I’m feeling too raw for that.  This week I’m feeling a lot of mixed emotions, and I wanted to let them all out, both good and bad.  Because ThinkGeek was a beautiful, shining thing, and an important cultural thing, and I feel like it was taken from us too soon, by people who were greedy and yet probably didn’t end up getting rich, people who thought they knew what we wanted more than we did, people who probably looked down on us a little bit but had no problem profiting off our talents.  Those were not good people.  But still they cannot sully the memory I have of what ThinkGeek meant to me, and I’m sure what it meant to all its former employees.  We got to do something we loved, every day, and we kicked ass at it, and they even gave us some money for it.  And you can’t say fairer than that.



__________

1 Remember, I wasn’t actually there for ThinkGeek’s birth, so you’re getting all this second-hand.  My memory is no doubt faulty in places, and the memories of those that told me the original stories may have been faulty in places, and anyway “what really happened” is a bit of an aspirational myth for all stories, if you think about it.
2 Many would say that Wizards also has gone downhill ever since, but it must be admitted that they’ve had a bit of a resurgence of late.  Hopefully they can end up being the exception to this pattern.
3 Or maybe it wasn’t coincidental at all; that’s a part of the story I was never privvy to.
4 By the way: July 10 is Nikola Tesla Day.  Be sure to celebrate.
5 To be clear, this pattern isn’t limited to just geeks: creative types of all sorts have experienced this exact pattern, and they’ve also been accused of being bad at business.  It just so happens that geeks are the ones I’m most familiar with.
6 I’ve actually told this story before, in my post on fate.  However, at that time, I was being a bit more coy about what company I was talking about.  At this point, I don’t really see much point in such subterfuge.
7 Okay, except for the K-pop.  Sorry, Jon: I still can’t get behind you on that one.










Sunday, September 23, 2018

All the people in the dance will agree


This week we had our annual summer party at $work.  Yes, yes: calling a party held just 3 days before the autumnal equinox a “summer” party is pushing some boundaries.  But in this case our party got delayed so that it could coincide with an announcement.  I’m not actually allowed to discuss that (yet), as it’s not public (yet), but I suppose I agree that delaying the party in this particular case made sense.

The party itself was quite lovely.  The company rented a big house right on the beach at Playa Vista, and we drank and played beach-type games, then we sat around and drank, and then we danced for a bit.  Oh, and drank ... to be honest, I mostly drank during the dancing.  I think my dancing days are mostly behind me, at this point.  Shitty knees, weak ankles, a herniated disc ... plus, realistically, I was a pretty crappy dancer even before all that.  But it’s still fun to watch other people dance.  And, did I mention the drinking?  That part was nice.

But mostly it was nice to hang out with my peeps from work, the vast, vast majority of whom are amazingly awesome people who are fun to hang out with on a beach with a cold drink in hand.  I’m glad we got to do that again this year, and I look forward to doing it again for many years to come.

Next week, a proper post.









Sunday, August 6, 2017

A Brief History of Mistakes


The other day, my boss Steve1 asked me about a ticket I had written a long time ago.  Was the problem I had reported still a problem, he wondered?  Well, yes, technically speaking, it was still a problem, I responded, but not a very big problem.  After all these years, we’ve mostly worked around the minor pains-in-the-ass it causes.  And while it could cause a bigger problem, and in fact had just done so no more than two weeks ago, the truth is, as I said to him, somewhat tongue-in-cheek:

That blip was the first one in forever, and, try as I might, I couldn’t get Arya2 to be worried about missing an entire day in his reports.


Now, some hours after I sent this, as I am wont to do, I started wondering about my own choice of words there.  I made it sound like I had actually put some effort into trying to convince Arya that the problem was significant, even though the most likely person to be impacted by it was him, and he was obviously not worried about it.  Not to mention that, if he did decide to do something about it, the something he would do is make a ticket for me to fix it.  So whatever effort I was putting into this argument was only going to end up making work for myself if I “won.”  And yet, it sounds like I put some effort into this argument because ... I actually did.  So, now I wondered: why?

And thus we begin what I suppose is now part 4 of my ad hoc series, “Why I’m a Pain in the Ass at Work.”  Last time I briefly reviewed the first two installments, then went on to recast my being a stubborn ass in as positive a light as I could manage, which mainly consisted of pointing out that I’m trying to keep from making—and/or trying to help someone else avoid making—some mistake that I’ve already made once and don’t have any desire to repeat.  And, unlike last installment, I’m not going to say today that I think there’s more to it than that.  On the contrary, I think I might have nailed it down pretty thoroughly at this point.

What I was pondering that led to today’s post, instead, was why sometimes (as in all 3 of the incidents that spawned the previous posts) I seem like I can’t let it go, and will go overboard in my objections, whereas sometimes (such as with this particular incident) I put up a token resistance, but then I cave pretty easily.  I mean, either way, it’s a mistake that I’ve seen happen before, right?  Either way, to let it happen again is going to be frustrating ... right?

Well, after much pondering and soul-searching, I’ve come up with an answer.  I wish I could tell you that I thought that, when people have this reaction, they base the intensity of their argument on their assessment of how much damage the mistake could cause, or perhaps on the likelihood of that mistake actually happening (is it nearly guaranteed, or a longshot that anything will ever go wrong?).  I do wish that were the case.  But I don’t believe it is.  I believe that rather it depends on whether you were the one who had to clean up the mess or not.

See, I’m not the only person who has these types of reactions.  Oh, sure: I’m probably the biggest pain-in-the-ass at my current job, I won’t try to deny that.3  But I am, occasionally, believe it or not, on the other side of this debate.  I am, occasionally, the one who’s saying, “yeah, okay, maybe that could happen, but that doesn’t sound so bad.”  Where this most often comes up, for instance, is with two of my co-workers who are very focussed on security.4  They’re always trying to convince me that we should implement this or that piece of authentication that I’ve no doubt will leave us safer, but which will probably be a big hairy annoyance to me in the meantime.  And, sure, I nearly always lose these debates,5 and nowadays my ssh key has a more-than-40-character passphrase, and my hard drive is encrypted, and I’m about to start undergoing the horror that is Multi-Factor Authentication.  But, still, whenever the topic comes up, I’m nearly always the one going, “I hear you about what could happen, but I’m finding it hard to get too worried about that.”  And it’s certainly not because I’ve never seen inferior security measures fail.  And I’m pretty sure it’s not because doing it the “right” way is going to make more work for me: I’ve argued to the death for making more work for myself on many an occasion.  Nope, I’m pretty sure that it’s because, whenever I have seen such things, it was never my job to clean up the inevitable mess.

Contrariwise, when it’s a question of making a sub-par design decision, I get very invested in making sure we don’t go down a road that is going to cause us heartache one day, because in that case “us” inevitably means “me.”  And, even if it doesn’t mean me in the future, it certainly has in the past.  I’ve seen the crap that can fall out of one bad choice, and I’ve had to go in there years later and try to figure out how to undo it.  And those are painful memories.  And, as far as I’m concerned, these are things that will happen, eventually.6  So it’s not a question of “if” but rather “when.”  I distinctly remember one such discussion, which happened to also include my boss.  He seemed genuinely puzzled at my passion for whatever particular design principle was at stake.  Intellectually, I believe he knew that what I was predicting could happen—maybe even he knew it was likely to happen.  It just didn’t seem that big a deal to him if it did, and I bet that’s because he just never drew that short straw of having to wade into the cesspool and shovel out the shit.  And, in the end, I let that particular point go because I was pretty sure that, whenever the shit hit the fan, the fan was most likely going to be pointing at someone else anyway.7

And, in the situation that spurred this post, I also knew that it was probably pretty unlikely that I personally would be responsible for the clean-up.  This was really only going to go wrong if the particular day that was missing from reporting—and, really: not even missing from all of reporting, just missing from one subset of reports—happened to contain a significant number of results from one customer, or maybe a set of customers, and therefore the lack of those results would significantly alter an aggregated view (likely a monthly one) in a way that was big enough to make a (business) difference, but small enough not to be glaringly obvious that data was missing, and if the report went through enough hands that the numbers were used to make some wrong decision, or sent the business off on a wild-goose chase involving many employees and lots of wasted time, but not so many hands that someone along the line didn’t remember that, hey, didn’t someone say there was a whole day missing somewhere?  And damn, that’s a lot of “if"s.  And, if anyone comes to me about it, I get to point out that I already told everyone I could imagine to watch out for this, and the worst that can happen is that someone makes a ticket for me to fix it, which is honestly what I was sort of pushing for in the first place.  So, you know: no skin off my nose.

So, yeah, I did try a little bit to convince Arya that he should be worried about a missing day in his reports, because if the worst case happened, I would feel bad for him (’cause he’s a genuinely good guy, and I love working with him, and I hate to see him stressed), but, no, I didn’t try that hard, ’cause, in the end, Arya gets to make his own decisions (and his own mistakes), and I can’t make ’em for him.  But maybe also because—just maybe—not only am I pretty sure that I won’t have to clean up the mess in this situation, but I’ve never had to clean up the mess in any past, similar situation.  And I’ve seen some.  Ignoring reporting data glitches will nearly always come back to bite you in the ass, sometimes in small ways, sometimes in big ones.  But it’s never been something I’ve personally had deal with.  Never have I personally been the one who had roll up their sleeves, muttering non-stop profanities under their breath, throwing all their current plans and schedule out the window, and start doing shit-work to clean up all that fertilizer that just passed through the oscillating air distribution device.

And I’m trying to figure out if that makes me a bad person.

I hope not.  I hope that I’m just a person who, like pretty much all people, is subject to confirmation bias (or maybe some other kind of bias; Wikipedia cautiously suggests correspondence bias), and that sometimes I’m on the receiving end, and sometimes I’m on the other end.  Maybe understanding that will help me handle these situations a little intelligently, and hopefully a little more diplomatically.

Or maybe I’m just fooling myself again.  But either way I found it an interesting meditation.



__________

1 Okay, Steve is technically my boss’s boss.  But I don’t usually think of him that way.

2 Arya is the head of the business analyst department, and the person on the business side that I work most closely with.

3 Yep, and probably the biggest pain at my last several jobs.  I can own that too.

4 One of whom is my actual boss, and the other of whom is our sysadmin.

5 Did I mention that one of the other parties was my boss?

6 Well, unless the code doesn’t last that long.  But I don’t accept that as a useful counterargument; that’s pretty much like saying “it’s okay if we build a completely flimsy house, because there’s a decent chance we’ll tear it down before it gets the chance to fall over.”  Which is cold comfort if you’re the one who has to live in the house in the meantime.

7 Interesting side note: the co-worker who was most likely to have said fan pointing at him has since left the company.  So now I suppose I’m back in the running for most-likeliy-to-be-spattered.  Lovely.









Sunday, July 26, 2015

Series Listing: The Barefoot Philosophy


Barefoot Software was the business I ran for 12 years.  This series explains the culture of Barefoot, why it was radically divergent from most other businesses of its time, and how it dovetails with many of the newer business philosophies we’re seeing emerging today (in particular, comparing and contrasting to Netflix and Valve).

This series is completed.



Sunday, January 25, 2015

All work and no play is pretty much the same as all play


I’m doing some work this weekend, so I’m not doing a normal blog post.  Let me stress that this is not like a Lumbergh type situation.  In fact, this job has been quite courteous of my weekends, especially compared to $last_job.  So when something comes up and I know that people would be inconvenienced if I didn’t work on it over the wekend (which happens pretty rarely), I actually want to put in the extra work.  Plus I love what I do, so then is it really work?  As Confucius (supposedly) said:

Choose a job you love, and you will never have to work a day in your life.


Of course, saying “I love what I do” is not the same thing as saying “I love my job,” but, as it happens, I do that as well.  I don’t know that I could describe it as a perfect job, but I also don’t know what any of my bosses could give me that they haven’t already, so perhaps that’s as close to perfection as makes no never mind.  In my blog post about what employees want, I said that the most important things are respect, trust, and freedom, and I have those in spades.  So it pleases me to do nice things for those I work for, and it’s fun, so sometime I do a little extra, if the mood strikes me.  Which, this weekend, it has.

So I’m going to go immerse myself in some Perl code and try to accomplish a few things to make my coworkers’ lives easier.  Perhaps next week I’ll be inspired to write a more complete post.

Sunday, December 14, 2014

Obstreperousness as a Virtue


I am sometimes a giant pain in the ass at work.

Don’t get me wrong: I’m not always a giant pain in the ass.  Often I’m quite pleasant.  Sometimes I’m even agreeable.  But occasionally I lock into stubborn mode and I won’t let go of a point of view, even when I’m hopelessly outnumbered.  When one is younger, one can look upon one’s obstinacy as persistence, can see refusal to compromise as being a bastion of integrity.  Of course, as one gets older, one realizes that they’re really both the same thing.  And, once you realize that every good quality you have is also a bad quality, sticking to them no matter what because they’re “the right thing to do” doesn’t fly any more.  You need better justifications than that.

Thus I keep examining my own motives in an attempt to figure what makes me tick, even though I know that’s doomed to failure.  In fact, on this very topic I’ve already waxed authorial not just once, but twice.  I’m not saying either of those posts are wrong now ... just that I continue to look for something more, even more to help explain my behavior.

The first time I concluded that I hate seeing people make what I think is a mistake, and that’s a part of it.  Maybe a smaller part than that post made it out to be, but it wasn’t a completely useless observation.

The second time I talked about my number one source of frustration in the corporate world.  That’s still relevant too; in fact, at work this week I trotted out that very same story to tell my coworkers.*  But I still think there’s more to be teased out here.

After quite a bit of reflection, I’ve come up with this:  I figure if you’re going to hire someone like me—by which I mean someone with this much gray in their beard who is this much of a pain in the ass—then you do it for two reasons: you want my experience, and you want me to be vocal about it.  If you didn’t want my experience, you could hire someone younger.  And if you didn’t want me to be vocal about it, you could definitely hire someone who was a lot easier to put up with.

Hiring someone for their experience means hiring them for their mistakes.  As a popular quote tells us:

Learn from the mistakes of others.  You can’t live long enough to make them all yourself.**


So, if you’ve hired me, and you’ve kept me around for a while, and you genuinely seem to value me, then I assume that you want the benefits of my mistakes, and you want me to let you know in no uncertain terms when you’re about to repeat one of them.  And to keep on letting you know if you continue to keep on trying to make that mistake.

Now, don’t get me wrong: I’m not saying you always have to agree with me.  In fact, I think it’d be pretty disastrous if everyone always agreed with me, or always agreed with anyone.  Difference of opinion, as I am fond of saying, is what makes the world go ‘round.  Which is to say, the world would be a pretty boring place if we all agreed on everything.  And how would we ever learn anything without other people challenging our assumptions?  No, if I’m saying that me disagreeing with you is a good thing (which is what I seem to be saying, if I’m saying that my pointing out that a plan of yours may be a mistake is valuable), then I have to accept that you disagreeing with me must be an equally good thing.  In the big picture, I mean.  On any given point, I’d really prefer you stop disagreeing with me and just do as I advise.  But, overall, I can accept that, some percentage of the time, you’re going to disagree with me, and, some percentage of the time, I’m going to lose that fight, and, overall, that’s good.  But I think there are different ways to disagree.

For instance, if I say “if you do this, things could go wrong” and you (“you” in this scenario are my boss, remember) say “yeah, they could, but the rewards outweigh the risks” ... well, that’s a tough argument to beat.  Maybe we can debate the value of the rewards a bit, or the seriousness of the risks, but in general if you know the dangers and you’re willing to risk them for whatever the upsides are, I can’t argue with that.  Business requires risk.  Opportunities have costs, and sometimes you just have to pay them.  You roll the dice, pray the worst never comes, but, if it does, you just deal with it.  Because it was worth it.  If you don’t take risks in business, you get left behind.  Rapidly.

On the other hand, if I say “if you do this, things could go wrong” and you say “nah, I don’t think they could,” or perhaps “well, they couldafter all, anything could happen—but the chances are so low it’s not worth worrying about” ... if you say that, then I may just have to dig in.  Because what I’m telling you is, here’s a mistake I’ve already made.  I’m not talking about some theoretical consequence here: I know it can happen because it already happened to me.  I’ve lived through this, at least once (and, the older I get, the more likely it was more than once), and the resulting unpleasantness is burned into my memory, and I’d really prefer not to suffer through it again, thankyouverymuch.  This is why I also tend not to accept an answer of “yes, that could happen, but that’s okay; we’ll just deal with it.”***  ‘Cause, trust me: if it was no big deal to “just deal with it,” I would not be doing my giant-pain-in-the-ass impression.

Now, let me stress that I’m not unhappy with the way the these sorts of debates are unfolding at my current job.  In fact, curiously, the fact that the discussions have been so reasonable has been the impetus for my meditation on why I get so stubborn.  In past jobs, the pain of beating my head against a brick wall has somewhat dulled my capacity for self-reflection.  In this job, I have some confidence that the folks who hired me can and will take my obstreperousness in the spirit in which it is intended.  Still, I think it’s worth exploring why I feel so passionate about some of these positions, and examining which circumstances trigger my response and why.  Even it’s only for myself.  Because I think that understanding ourselves is one of the hardest things to get right, but one of the most worthwhile endeavors we can undertake.



__________

* If they would just have the good grace to read this blog I keep telling people not to read, I wouldn’t have had to retell the story.  But one can’t have it all, I suppose.

** Like many quotes floating about the Internet, this is attributed to a bewildering multitude of people, including Martin Vanbee, Sam Levenson, Hyman Rickover, John Luther, Eleanor Roosevelt, and Groucho Marx.  Most of whom I have no idea who they are.

*** This was the favorite tactic of my previous boss.









Sunday, September 14, 2014

Worth Striving For


A few days ago I was talking to the CEO of my company about why I love this job so much.  I found it hard to put into words ... the best I could come up with was that I had finally found a job where I was allowed—even encouraged—to fix things.  At my last job (and at many of the companies I’ve worked for, both as employee and contractor), if you wanted to fix something that was broken or ugly, you had to have meetings about it, and you had to present business cases for it, and you had to prove to someone that it was going to make money (or save money) in some way.  At the new job, if something’s broken (or ugly), we just say: fix it.  And no one tells you how to fix it.  They just trust that you will do it the best way you know how.

Trust, you may recall, is one of the three cornerstones of what employees want, according to the Barefoot Philosophy.  So that’s a big part of the attraction, certainly.  But this is a bigger issue, touching on the concept of craftmanship that I brought up before, but only scratched the surface of.  I’ve also made a business case for why crap needs to be fixed, but this is a different side of that coin.  And I wanted to expand on this topic, partially because it would be nice to tie all those disparate thoughts together, but mainly because I was frustrated by my inability to capture the gestalt of this idea in that extemporaneous discussion with my chief executive.  But of course I’m not good at speaking off the cuff.

Then again, that’s why I have a blog.

Perhaps the easiest way to explain it is with an extended analogy.  Imagine software developement as being like building a house.  Now, there are different aspects of home construction.  Obviously the most important aspect is functionality: you need working plumbing, a sound electrical system, structural integrity, and so forth.  But never discount æsthetics.  Nobody wants to live in an ugly-ass house.

Of course, the vast majority of the coding that we programmers do is not building a new house—it’s renovating.  The house is already there when we show up; the owner just needs some repairs, or perhaps a new bathroom, or maybe even a whole new wing added on one side.  It’s often said (even by programmers) that programmers prefer writing new code to maintaining old code.  There’s some truth to that, of course.  But not as much as it seems on the surface.  There’s nothing wrong with working to maintain a beautifully built, solidly constructed old house.  Sure, you can’t go crazy and go all Frank Lloyd Wright or John Lautner on it.  The basic layout is there, and there’s only so much you can do to it.  But the popularity of home improvement shows—from modern reality TV shows like Extreme Makeover: Home Edition to the public television classic This Old House, which is still on the air after 35 years—shows us that fixing up an existing structure can be interesting, challenging, intellectually stimulating ... all the things you could ask of a construction project.  I’ve worked on a few old codebases that were still a lot of fun and gave me plenty of opportunity to exercise my creativity and leave my mark, including the one I’m working on now.

But most of them aren’t like that.  Most of them are a kind of horror show train wreck.  Which is something we all end up slowing down to watch, with a guilty sort of fascination, but it’s quite another thing to be inside it while it’s happening.  Is it any wonder that most of us are desperately trying to rewrite parts of—if not the entirety of—our old codebases?  And the reason most of them are so awful is because of this very issue that I’m trying to explain.

See, working at my last job (and, as I say, for many of my previous employers) was a bit like doing a renovation for a homeowner who tells you “Just make sure the toilets flush, and the lights come on when you hit the switch, and the walls don’t fall over.  We don’t really care if it looks pretty or not.”  Which doesn’t sound so bad until you start getting into the details of it.  “Just patch the pipes with duct tape,” they tell you.  “Yeah, we know it’s not waterproof, but a few little puddles here and there are no big deal, and actually replacing the bad plumbing would take too long and be too expensive.”  And then they say, “You know what? just leave those exposed wires there.  We’ll put up some signs warning people not to touch them.  Actually patching the drywall is too much trouble, and we’ve got other stuff for you to work on.”  And then it gets to the point where they’re trying to convince you to prop up the walls with old two-by-fours from the backyard that still have rusty nails sticking out of them.  You can probably imagine how scary it is to walk into a job like this.  But what many people forget about is how utterly depressing it is to be the guy who let things get this bad.  Not by choice, of course.  But, if no one will let you fix anything ...

Part of the reason this is so frustrating is that some of this shit is actually dangerous.  Show me a programmer who hasn’t been told to ignore a bug that they knew was screwing over customers and I’ll show you a programmer at the start of their career.  Every business makes that choice, and I will even admit that it’s not always the wrong choice.  A bug that only affects a few customers but will cost many engineer-weeks to fix is not a sane thing to tackle.  But it’s one thing to make that call one time, and quite another to make it over and over again.  And let’s not dismiss the soul-crushing anguish of the raw ugliness of it all: you’re embarrassed to admit you were a part of the crew, and you’re constantly apologizing for your part in the mess.  Hell, it doesn’t even stop when you quit: at my most recent conference, I was still apologizing to employees that had been hired by my ex-employer after I left.  “We tried to make it better,” I would say, eyes downcast.  “But we just didn’t have the political capital.”  That’s a polite way of saying “our bosses wouldn’t let us fix anything.”

So it may sound a little weak to say “I really love my job because they let me fix things,” but try to understand it from the opposite point of view: I really hate a job where they won’t let me fix things.  It’s depressing to have to work in that environment day after day.  And, if there are any businesspeople out there reading this, let me try to put this into terms you can appreciate: this is a question of retention.  When you refuse to let people fix things, you make them miserable.  Oh, I can tell you that there are direct fiduciary benefits to a culture of improvement (and that’s true, although they’re notoriously hard to measure), but the real gain is that you keep your best, most productive employees happy, and you make it easier to hire more of the same, and if you can’t see how that is going to help your bottom line, then there’s nothing more I can say.  Here’s a great quote attributed to Hosea Ballou:

No one has a greater asset for his business than a man’s pride in his work.


I suspect this is how my CEO views it.  I don’t know for sure, because he hasn’t told me, but I’m guessing that he thinks to himself, well, my tech team always delivers when I ask them to, and sometimes even when I don’t, so if they want to go off and fix things I didn’t ask them to, and that makes them happy, then, more power to ’em.  As long as we keep doing the things that make him happy, and make the company money, he’s happy enough to let us take a little pride in our work.

And that’s what it comes down to, in the end.  I consider myself a craftsman, as I said—perhaps I should go even farther, as did web designer Richard Glover, and call myself an artisan.  I take great pride in what I produce, and I need to be producing things I can be proud of.  Give me a job that allows that—nay, encourages it—and I’m all yours.