Stories about Software


The Whiteboard Interview: Adulthood Deferred

I haven’t traveled this week (at least, not for work).  As a result of that, I’ve sat at home, where I tend to have somewhat higher social media consumption.  I therefore couldn’t help but see this post about “confessing coding sins.”

Twitter has, apparently, overflowed with established software developers ‘confessing’ that they would fail Gigantech Inc’s whiteboard/trivia interviews.  I’d like to go on record to point out that I ranted about the foolishness of this practice long before DHH made doing so cool with this tweet.

Here we have legendary techie David Heinemeier Hansson confessing that the Silicon Valley Gigantechs of the world would fail him out of their phone screens.  His tweet offers a compelling symmetry.  After all, when a cranky Thomas Edison invented the ineffective fad known as the “job interview” (that we haven’t bothered to revisit in the last 100 years), his interview would have failed Albert Einstein.

So, when it comes to the humble job interview, we at least know that it’s consistent.  It fails at its only job just as miserably today as it did in the beginning.  All of the MegaTechs out there in The Valley (and emulators around the world) would have passed on hiring meteoric value-creator DHH, thus calling into question the ubiquitous and vacuous claim of every company out there that “we only hire the best and brightest.”

But let’s come back to DHH a little later.  First, to celebrate the coming spring, I want to talk about baseball.

Wins Above Replacement (WAR)

Even if you don’t enjoy the sport of baseball, you should at least appreciate it for its data.  Unlike many sports out there, baseball happens transactionally.  The pitcher throws a pitch, and then a bunch of easily recorded stuff happens before play stops and this all starts over.  Oh, and we’ve kept logs of this going back 150 years or so.  This property has given rise to an entire discipline of statistics called sabermetrics.  So even if you don’t like home runs and hot dogs, you can at least appreciate the Big Data.

Baseball has a fascinating stat known by industry nerds as “Wins above Replacement (WAR).”  I’ll quote them directly on the meaning.

WAR offers an estimate to answer the question, “If this player got injured and their team had to replace them with a freely available minor leaguer or a AAAA player from their bench, how much value would the team be losing?”

Let me parse out the baseball jargon and simplify.  It asks, “how much value (in wins) does this player provide compared to an unremarkable replacement?”  Modern baseball clubs wager hundreds of millions of dollars answering this question.  A player with WAR above 5 commands that kind of money whereas one with a negative WAR gets a pat on the butt and an imminently unremarkable minor league contract.

WAR ain’t perfect.  But it pretty reasonably approximates player financial value.

What does any of this have to do with the job interview or whiteboard coding algorithms?  Well, the job interview represents the business world’s ludicrous attempt to calculate VAR (value above replacement) of prospective hires.

Read More


When is It Okay to Turn off Static Analysis Guidance

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, download CodeIt.Right and give it a try.

The balance among types of feedback drives some weird interpersonal dynamics and balances.  For instance, consider the rather trite (if effective) management technique of the “compliment sandwich.”  Managers with a negative piece of feedback precede and follow that feedback with compliments.  In that fashion, the compliments form the “bun.”

Different people and different groups have their preferences for how to handle this.  While some might bend over backward for diplomacy others prefer environments where people hurl snipes at one another and simply consider it “passionate debate.”  I have no interest arguing for any particular approach — only in pointing out the variety.  As it turns out, we humans find this subject thorny.

To some extent, this complicated situation extends beyond human boundaries and into automated systems.  While we might not take quite the same umbrage as we would with humans, we still get frustrated.  If you doubt this, I challenge you to tell me that you have never yelled at a compiler because you were sure your code had no errors.  I thought so.

So from this perspective, I can understand the frustration with static analysis feedback.  Often, when you decide to enable a new static analysis engine or linting tool on a codebase, the feedback overwhelms.  28,326 issues the code can demoralize anyone.  And so the temptation emerges to recoil from this feedback and turn off the tool.

But should you do this?  I would argue that usually, you should not.  But situations do exist when disabling a static analyzer makes sense.  Today, I’ll walk through some examples of times you might suppress such a warning.

Read More


Secrets of Maintainable Codebases

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look at the tech debt quantification features of the new NDepend version.

You should write maintainable code.  I assume people have told you this, at some point.  The admonishment is as obligatory as it is vague.  So, I’m sure, when you heard this, you didn’t react effusively with, “oh, good idea — thanks!”

If you take to the internet, you won’t need to venture far to find essays, lists, and stack exchange questions on the subject.  As you can see, software developers frequently offer opinions on this particular topic.  And I present no exception; I have little doubt that you could find posts about this on my own blog.

So today, I’d like to take a different tack in talking about maintainable code.  Rather than discuss the code per se, I want to discuss the codebase as a whole.  What are the secrets to maintainable codebases?  What properties do they have, and what can you do to create these properties?

In my travels as a consultant, I see a so many codebases that it sometimes seems I’m watching a flip book show of code.  On top of that, I frequently find myself explaining concepts like the cost of code ownership, and regarding code as, for lack of a better term, inventory.  From the perspective of those paying the bills, maintainable code doesn’t mean “code developers like to work with” but rather “code that minimizes spend for future changes.”

Yes, that money includes developer labor.  But it also includes concerns like deployment effort, defect cycle time, universality of skills required, and plenty more.  Maintainable codebases mean easy, fast, risk-free, and cheap change.  Here are some characteristics in the field that I use when assessing this property.  Some of them may seem a bit off the beaten path.

Read More


What’s in a Name? Spelling Matters in Code

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, check out GhostDoc.

Think back to college (or high school, if applicable).  Do you remember that kid that would sit near the front of the class and gleefully point out that the professor had accidentally omitted an apostrophe when writing notes on the white board?  Didn’t you just love that kid?  Yeah, me neither.

Fate imbues a small percentage of the population with a neurotic need to correct any perceived mistakes made by anyone.  XKCD immortalized this phenomenon with one of its most famous cartoons, that declared, “someone is wrong on the internet.”  For the rest of the population, however, this tendency seems pedantic and, dare I say, unpleasant.  Just let it go, man.  It doesn’t matter that much.

I mention all of this to add context to the remainder of the post.  I work as a consultant and understand the need for diplomacy, tact, and choosing one’s battles.  So, I do not propose something like care with spelling lightly.  But I will propose it, nonetheless.

Now I know what you’re thinking.  How can caring about spelling in code be anything but pedantic?  We’re not talking about something being put together to impress a wide audience, like a newspaper.  In fact, we’re not even talking about prose.  And code contains all sorts of abbreviations and encodings and whatnot.

Nevertheless, it matters.  When English words occur in your code, spelling them right matters.  I’ll use the rest of this post to make my case.

Read More


How to Get Coding Standards Right (and Wrong)

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, download NDepend and give it a try!

Nothing compares with the first week on a new job or team.  You experience an interesting swirl of anticipation, excitement, novelty, nervousness, and probably various other emotions I’m forgetting.  What will your new life be like?  How can you impress your teammates?  Where do you get a cup of coffee around here?

If you write code for a living, you know some specific new job peculiarities.  Do they have a machine with runnable code ready on day one?  Or do you have to go through some protracted onboarding process before you can even look at code?  And speaking of code, does theirs square with elegant use of design patterns and unit testing that they advertised during the interview process?  Or does it look like someone made a Death Star out of bailing wire and glue?

But one of the most pivotal moments (for me, anyway) comes innocuously enough.  It usually happens with an offhand comment from a senior developer or through something mentioned in your orientation packet.  You find yourself directed to the coding standards document.  Oh, boy.

At this point, I start to wonder.  Will I find myself glancing at a one-pager that says, “follow the Microsoft guidelines whenever possible and only include one class per file?”  Or, will I find something far more sinister?  Images of a power-mad architect with a gleam in his eye and a convoluted variable name encoding scheme in his back pocket pop into my head.  Will I therefore spend the next six months waging pitched battles over the placement of underscores?

Ugh, Coding Standards

In this post, believe it or not, I’m going to make the case for coding standards.  But before I do so, I want to make my skepticism very clear.  Accordingly, I want to talk first about how coding standards fail.

Based on personal battle scars and my own experience, I tend to judge coding standard documents as guilty until proven innocent.  I cannot tell you how many groups I have encountered where a coding standard was drafted, “just because.”  In fact, I’ve even written about this in the past.

Read More