Stories about Software


Some Announcements: Podcasts and T-Shirts and Partnership, Oh My

This post will be neither how-to nor rant, neither philosophical musing nor observation.  Instead, I’m going to offer a handful of pieces of news.  I’m not sure that it’s anything yet polished enough to send to my mailing list, in case you’re wondering why I’m not making a rare use of that.  I’d prefer to save that for more official offerings and announcements.  This is just a handful of things I’d like to collect a bit of data on.

A Podcast Appearance

I was recently invited to appear on Developer on Fire, a podcast hosted by Dave Rael.  If you’ve never had the pleasure, I suggest giving it a listen.  Dave has had quite an impressive list of guests, including Scott Hanselman, Uncle Bob, and DHH among others, so it was both flattering and fun to be added to the roster.  If you want specifically to check out my interview, you can find it here.

I won’t tip my hat with specifics just yet, but I will say that this isn’t the last podcast on which you’ll be able to catch me, so stay tuned!

The Expert Beginner T-Shirt

My wife and I have been toying with 4 Hour Work Week concept of merchandising a bit lately.  In thinking about what we might be able to do together, combining the reach I have with her design chops, the thought of making something around the Expert Beginner emerged (my turn of phrase, her art work).  I’ve also been obsessed with extremely comfortable T-shirts lately, having been exposed to the absolute pinnacle of T-shirt comfort in the form of Pluralsight’s 2015 Author Summit T-shirt.  It is sublime.

Long story short, we’re looking at making a comfy line of Expert Beginner T-shirts.  To see if anyone would actually want this stuff, we’re maybe going to do a kickstarter, but that requires a prototype, which we’ve narrowed down to 3 shirts.  She and I were debating the merits of them, when she suggested we turn it over to a vote of potential customers.

Here are the fronts and backs of the 3 candidates.

Shirt 1

Mock Up 1--Front

Mock Up 1 and 2--Back

Read More


Github and Code Review: A Quiet Revolution

Editorial Note: I originally wrote this post for the SmartBear blog.  Go check out the original here, at their site.  Stick around and check out some of the other authors and posts over there if you’re so inclined.

When the winds of change blow through the programming world, they don’t necessarily hit everyone with equal force.  The start-up folks cranking out reams of Ruby code on their Macs probably feel a gale-force headwind, while a Software Engineer III toiling away in Java 1.5 for some Fortune 500 bank might feel only the slightest breeze.  But on a long enough timeline, the wind changes things for everyone.

Github has proven nothing short of a revolution for a lot of small, nimble organizations, startups, and cutting edge companies.  For heavily regulated, locked down enterprises, this effect is certainly muted, but I would argue that its subtly perceptible nonetheless.  Github is changing a lot of things about software development, and this includes the nature of code review.

Let’s consider some properties of Github.

Social Coding

Github is often described as a social network for programmers.  The term “social coding” has even appeared in some of Github’s marketing material.  It is a platform meant, specifically, for maximum interaction.

Sure, Github is a vehicle for open source contributions, but that’s hardly a difference-maker for them.  Sourceforge was around for a long time and it would host source control for open source projects for free.  There have also been other communities oriented around contributions and code sharing, such as Code Project.  Github, however, came along and truly married social with coding, introducing feeds, followers, ubiquitous collaboration tools, and even a social network graph.  Having cute octopus buddies as their mascots probably didn’t hurt matters either.


The result is an unprecedented amount of enthusiasm for global sharing of code.  20 or even 10 years ago, you probably would have hoarded source code of a side project.  You wouldn’t have wanted to give away your intellectual property and you’d probably also have been embarrassed until you could tidy it up to put your best foot forward.  Now the default is to throw your side work up on Github and show it off for the world and your followers to see.  Code is being shared as never before.

Read More


A Manager’s Guide to Legacy Code

Editorial Note: I originally wrote this post for the NDepend blog.  Go check out the original here, at their site.  If you like posts about static analysis, code quality, and architecture, head on over and check it out.

If you have a sadistic streak and manage a team of software developers, it’s probably high entertainment to dredge up some old, dusty piece of software and then to task them with maintaining it.  If, on the other hand, you’re a normal human being and you’re asking this because it’s necessary for your business, you brace yourself.  After all, this is legacy software, and the reaction of the team is likely to be quite predictable.

Alright, let’s take a look at this thing.  Oh, man, look at that right there.  A global variable.  And — oh my god — there are dozens of these things.  Who even wrote this?  And, look at this over here.  That’s the kind of idiotic, backward code that we used to have to write 20 years and 6 language versions ago when this code was current.  But even when it was current, this code was horrible.  This was obviously written by a trained ape.

When you’re a developer, the only thing worse and more contemptible than the uninformed code you wrote years ago, is the code that someone else wrote years ago.  Not only is it alien to you in makeup and reasoning, this legacy code also features patterns that have gone out of date or even been forgotten.


But lest you, as a manager, assume that this is simply a matter of developers being prima donnas, consider that an encounter with legacy code bother developers precisely because it renders them less effective.  They’re professionals, wanting to do good work, and the lead balloon you’ve dropped in their lap is an impediment to that.

Read More


Applied Consultant Taxonomy to Prevent Confusion

A few posts ago, I proposed a taxonomy for software consultants.  My reasoning for doing so was that I wanted to attempt a bit of clarification.  As software has taken over the world, “consultant” is no longer singlehandedly up to the challenge of describing everyone working in software not associated with any particular domain.

So I proposed the terms software pro, specialist and consultant as a means of bringing some clarity.  At the end of that post, I also alluded to a future post, in which I would talk about the problems that crop up when one of these personas is mistaken for another.  This is that future post.

Having been in and around the consulting world for a long time now and having served time in all three of these roles, I’ve seen firsthand how weird and sometimes damaging confusion of these roles can be.  There are too many permutations of mistake for me to want to list all of them in a post, so I’ll stick to the ones that are the most common and interesting, in my opinion.

The Aggrieved Grunt

For better or for worse, rightly or wrongly, software pros are regarded as the grunts of the non-salaried software development world.  Consultants and specialists are hired in non-delivery and possible-delivery roles, respectively, which means that they’re being hired for their expertise.  Software pros are hired into delivery roles, and while their expertise may interest their clients, it’s their labor that’s being purchased.


A non-expert labor purchase has two interesting characteristics for our purposes here.

  1. It means that someone else, and not the software pro, is making the strategic decisions (i.e. “we’ve put together all the requirements and design specs and need you to code ‘em up”).
  2. It puts the software pro firmly on the hook for execution.

Significantly, the software pro’s charter looks a lot like the line-level developer’s charter.  After all, architects and team leads make strategic decisions, and managers supervise delivery rather than owning it.  The grunt coders on the team, by contrast, faithfully execute the strategic visions of others.  So if we map the consultant taxonomy to familiar team roles, consultants are roughly like managers, specialists are roughly like architects, and software pros are basically developers.

Read More


Is There Value in Having Non-Technical People Do Code Review?

Editorial note: I originally wrote this post for the SmartBear blog.  Go to their site and check out the original!  If you like this post, there are a lot of good ones there by a variety of authors, on topics like code review, API design, testing, and more.

Here’s a thought exercise for you. Should non-technical people participate in code reviews?

It’s off the beaten path, to be sure, but I think it’s an interesting philosophical consideration. We’re entirely used to code review as an exercise by developers and for developers. But is there a place or purpose for outsiders to review our code?

Why do it?

I’ll state up front my answer to that question: “yes, provided it happens in a specific, directed way.” But to convince you, let me offer some potential benefits that I see, depending on who reviews what.

  • In general, it could bring members of the team with different skill sets closer together. Developers learn the business domain; why not let the business people understand the developers’ world?
  • This could serve as a sanity check. Are developers writing code that accurately reflects the domain?
  • It could also force developers to write code that is cleaner, more readable, and more maintainable. Imagine having to write code that a non-technical person might understand.

I’ll offer more detailed rationale for this thinking shortly.  But I imagine you’d agree that these goals would be worth pursuing.  If an occasional, different style of code review can help, then it’d be worth doing.

Be careful with this.


But before I talk about what these reviews might look like and how they could help, it’s important to stress that I’m not proposing a radical change to the code review process.  What I’m proposing is an occasional exercise to offer a different perspective on the team’s code.  Having non-technical folks look at the code shouldn’t be a vehicle for micromanagement or for former techies to quibble over code.  It shouldn’t be exhaustive, since a lot of plumbing code will be nonsense to them.

Read More