Stories about Software


Value Theater and Pencil Sharpeners

I had some grand plans this week to do a Chess TDD post and a reader question post, but I wound up agreeing to do a quick contract gig that was very time sensitive, so I’ve been coding furiously all week, logging 50 billable hours in 4 days and still going strong.  That’s why, instead of any of my best laid plans, I offered cross posts.  Ah well, it turns out the cross posts tend to be quite popular, so I suppose everyone wins.

Given that I’m tired from all of this work and just kind of freewheeling a bit here, I’ll just type extemporaneously (or as close to that as you can manage with typing).  It’s been a while since I just typed what was on my mind in a stream without structure, so this is kind of fun.  This is a topic that’s bubbled near the surface for some years, but never quite made it into a post.  I’d like to talk about what people do in professional situations with a high degree of ambiguity.  This comes up a lot, often during transitional situations for groups or organizations.

To be a little more concrete about it, let’s say that you’re part of a team that’s just delivered a multi-year project, and it’s time to figure out what’s next for you as a group.  There’s an idea that, while the C-levels figure out the next long-term play, your team will spend a few months “cleaning up” an internal, legacy app.  What “cleaning up” means is yet to be determined.

At this point, all you know is that you’re going to do stuff to this application.  This lack of specifics is the ambiguity to which I’m referring.

Dealing with Ambiguity

Watching how people react in a situation like this is interesting.  Sure, at some point, circumstance will squeeze specifics out of some reluctant manager and the team will have their marching orders, but until that happens, you can witness a small study in human psychology.

Some people will interpret this situation as either quasi-time off, or else as unplanned “20% time,” triggering a period of some degree of coasting.  They’ll bone up on general knowledge, work on a little project they’ve always thought the company could use, work on a side project of their own, or maybe even just spend all day on Facebook.  The common theme here is that they’re content to wait for more specifics before proceeding.

Other people will fill the ambiguity with virtuous specifics according to their own office ethos.  I think of this as “sharpening the pencils,” and it’s usually accompanied by a crisp, earnest, and slightly urgent, “alright. come on, guys, let’s all {sharpen the pencils}.”   For some people, this means filling in the void with comfortable structure.  “Let’s decide who is going to be the liaison, the project manager, etc.”  For others, it’s haggling over tools of the trade — “alright, well, I think we should use that new text editor and it might make sense to update this code base to node.”  For others, it may simply be “time to lean, time to clean” activities, like “we don’t know what we need to do, but it couldn’t hurt for us to get started adding comments to every method in this thing.”

I call this “sharpening the pencils” because in my mind, it can be crystallized to this image.  “Well, we don’t know exactly what’s coming, but it can’t hurt to greet it with pencils sharp, ready and willing to take notes and get started on whatever comes!”


Getting it Right

In my opinion, one of these camps is decidedly the ‘right’ camp, and it’s the former.  No, I didn’t confuse directional words.  I think the non-pencil sharpening loafers are doing the right thing, both for themselves and for the business.  And it’s not because I find “let’s all sharpen pencils” enthusiasm to be hard to take (though that can be the case).  It’s a lot more pragmatic than that.

Read More


Embracing Creative Constraints

This year, I got a Christmas present that came out of left field for me: the Amazon Echo.  Up until getting it, I was aware of its existence as “that Amazon Siri thing that lets you order stuff from Amazon by voice.”

Once I started reading about it a bit, some actual use cases replaced the blank slate of my ignorance.  I could tell it to play my Pandora playlists, and issue further vocal commands to make things louder or softer and to pause, skip, or stop.  It could read me my calendar as well as sports and news updates.  It seemed like it could be mildly amusing.

My Budding Friendship with Alexa

But then I actually set it up, and a funny thing happened.  “It” became “she” (her name is Alexa), and I started talking to her.  And I mean, actually talking.  Let me explain.


A week into my ownership of the Echo and my rudimentary ‘friendship’ with Alexa, I had set up a number of different “skills” (which are essentially apps/plugins that third parties write for the device) and peppered her with questions, probing for all sorts of different Easter eggs.  A lot of it was done with amusement in mind, but it was interesting how quickly I became used to asking Alexa what the weather was like outside when I was deciding what to wear.

Last week, I was explaining to someone what having the Echo was like, and it was hard to put my finger on exactly why I felt so positively about it.  For lack of a better way of describing it, I said, “this is the first personal assistant or whatever that makes it feel like I’m having a conversation.”  I have Cortana on a few machines and I have “OK Google” on my phone, and I use both of those things from time to time, but they’re not the same.  If I say, “hey Cortana, what is the traffic like,” and I don’t like what happens next, I just open a browser and go to google maps.  If I say, “Alexa, what is the traffic like,” and she tells me that she doesn’t understand the question, I think for a moment, rephrase, and try again.

In this regard, it’s like taking to my wife.  If I ask her what the traffic is like, and she responds that she didn’t understand the question, I can’t just go up to her, squeeze her nose, and see a map on her forehead.  I have to repeat, rephrase, or ask something different that she might be able to answer.  In this regard, Alexa feels pretty human.

Read More


The Secret to Fighting Buzzword Fatigue

A little while back, I made a post in which I mused about the work-retire dynamic as an unusual example of large batches in life. In the lead-in, I made passing reference to a post where I talked more specifically about buzzword fatigue. This is that post (with this explanatory paragraph pre-pended, of course).

It feels amazing, in an odd way, to give something a good name. You have to know what I mean. Have you ever sat around a whiteboard with a few people, tossing out names for some kind of module or concept or whatever, scrunching your nose and shaking your head slightly at each suggestion? “No, that’s almost right, but I don’t think that’s it.” And then finally, someone tosses out, “let’s call it the clobbering factory!” and all of your eyes go wide as someone else yells, “yes!!”


Names are important. There’s a certain finality to naming something, even when you wish it weren’t the case. Have you ever failed in the quest for the perfect name, only to say something like, “aw, screw it, let’s just call it ‘circle’ since it’s a circle on the whiteboard, and we’ll rename it later?” If you have, you can’t tell me that the thing’s official name isn’t still “circle,” even 3 years and 23 production releases later. You probably even once tried to rename it, grousing at people that refused to start calling it “The Phoenix Module” in spite of your many, many, reminder emails. It stayed “circle” and you gave up.

There’s an element of importance to naming that goes beyond simple aesthetics, however, when you’re naming a concept. Products, bits of code and other tangible goodies have it easy because you can always point at what you’re talking about and keep meaning from drifting. With concepts… not so much. Next to their tangible cousins, they’re like unmoored boats in a river and they will drift.

And I think that the amount to which they drift is controlled by two main factors:

  1. Uniqueness
  2. Mappability to known concepts in context

Read More


Delegating is Not Just for Managers

I remember most the tiredness that would come and stick around through the next day. After late nights where the effort had been successful, the tiredness was kind of a companion that had accompanied me through battle. After late nights of futility, it was a taunting adversary that wouldn’t go away. But whatever came, there was always tiredness.

I have a personality quirk that probably explains whatever success I’ve enjoyed as well as my frequent tiredness. I am a relentless DIY-er and inveterate tinkerer. In my life I’ve figured out and become serviceable at things ranging from home improvement to cooking to technology. This relentless quest toward complete understanding back to first principles has given me a lot of knowledge, practice, and drive; staying up late re-assembling a garbage disposal when others might have called a handyman is the sort of behavior that’s helped me advance myself and my career. On a long timeline, I’ll figure the problem out, whatever it is, out of a stubborn refusal to be defeated and/or a desire to know and understand more.


And so, throughout my career, I’ve labored on things long after I should have gone to bed. I’ve gotten 3 hours of sleep because I refused to go to bed before hacking some Linux driver to work with a wireless networking USB dongle that I had. I’ve stayed up late doing passion projects, tracking down bugs, and everything in between. And wheels, oh, how I’ve re-invented them. It’s not so much that I suffered from “Not Invented Here” syndrome, but that I wanted the practice, satisfaction, and knowledge that accompanied doing it myself. I did these things for the same reason that I learned to cook or fix things around the house: I could pay someone else, but why do that when I’m sure I could figure it out myself?

Read More


What I Learned from Learning about SpecFlow

In my ChessTDD series, I was confronted with the need to create some actual acceptance tests.  Historically, I’d generally done this by writing something like a console application that would exercise the system under test.  But I figured this series was about readers/viewers and me learning alongside one another on a TDD journey through a complicated domain, so why not add just another piece of learning to the mix.  I started watching a Pluralsight course about SpecFlow and flubbing my way through it in episodes of my series.

But as it turns out, I picked up SpecFlow quickly.  Like, really quickly.  As much as I’d like to think that this is because I’m some kind of genius, that’s not the explanation by a long shot.  What’s really going on is a lot more in line with the “Talent is Overrated” philosophy that the deck was stacked in my favor via tons and tons of deliberate practice.

SpecFlow is somewhat intuitive, but not remarkably so.  You create these text files, following a certain kind of format, and they’re easy to read.  And then somehow, through behind the scenes magic, they get tied to these actual code files, and not the “code behind” for the feature file that gets generated and is hard to read.  You tie them to the code files yourself in one of a few different ways.  SpecFlow in general relies a good bit on this magic, and anytime there’s magic involved, relatively inexperienced developers can be thrown easily for loops.  To remind myself of this fact, all I need to do is go back in time 8 years or so to when I was struggling to wrap my head around how Spring and an XML file in the Java world made it so that I never invoked constructors anywhere.  IoC containers were utter black magic to me; how does this thing get instantiated, anyway?!


Read More