Stories about Software


Keep Your Codebase Fit with Trend Metrics

Editorial Note: Thanks to everyone who voted for a Developer Hegemony Cover.  I’ll tabulate the official results soon, but it looks like the dark cover is the clear favorite!

Second 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, take a look at the new version of NDepend.

A while back, I wrote a post about the importance of trends when discussing code metrics.  Metrics have impact when teams are first exposed to them, but that tends to fade with time.  Context and trend monitoring create and sustain a sense of urgency.

To understand what I mean, imagine a person aware that he has put on some weight over the years.  One day, he steps on a scale, and realizes that he’s much heavier than previously thought.  That induces a moment of shock and, no doubt, grand plans for gyms, diets, and lifestyle adjustments.  But, as time passes, his attitude may shift to one in which the new, heavier weight defines his self-conception.  The weight metric loses its impact.

To avoid this, he needs to continue measuring himself.  He may see himself gaining further weight, poking a hole in the illusion that he has evened out.  Or, conversely, he may see that small adjustments have helped him lose weight, and be encouraged to continue with those adjustments.  In either case, his ongoing conception of progress, more than the actual weight metric, drives and motivates behaviors.

The same holds true with codebases and keeping them clean.  All too often, I see organizations run some sort of static analysis or linting tool on their codebase, and conclude “it’s bad.”  They resolve only to do a better job in a year or two, when the rewrite will start.  However good or bad any given figure might be, the trend-line, and not the figure itself, holds the most significance.

Trend Metrics with NDepend

In that last post, I touched only on the topic, but not the specifics.  Here, I’d like to speak to how NDepend helps you with metrics.  I suspect that a lot of people know NDepend for its memorable visualization aids and its code rules and queries.  I don’t see as much discussion about the valuable trend tools, perhaps because they were release comparably recently.  In either case, I want to talk today about those tools.

Read More


Developer Hegemony: It’s a Wrap (And Check out the Covers)!

I think I started the initial writing of this book in the summer of 2015.  Then I spent the next year and a half or so writing it in my relatively limited spare time.

Some of this happened piled on top of 50+ hour weeks, by the fluorescent glow of a hotel room light.   Other times it was weekends at home.  But, wherever I found the time, I did my best to keep trucking.  I had a lot of fun doing it, but I have to say it proved a monumental undertaking.

A couple of weeks ago, I completed the initial draft of the book.  Just last night, I published the last significant draft (editing of the last quarter of the book still pending) to Leanpub.  Any subsequent publishes will come as a result of edits and not additions.  So, that’s it.

Thanks to all of the people that have purchased the book or have followed along as I’ve written it!

What Now?

Now, we enter the planning stage, in preparation for a real, no-foolin’ book launch.  We have yet to pick a date yet, but it looks like probably sometime in April.  Still a lot of work to do.

A few quick bullets to note.

  • The book now has a page on my site, here.  I’ll update this as I go, but this represents the ‘official’ Developer Hegemony site.  Look, developerhegemony.com links there, too!
  • I have likewise created a landing page to visit after reading the book.  Around the same time that I launch the book, I’m planning to shift my professional focus to move away from time for money consulting and toward content and productized services.  As part of this, I plan to start offering material on how to hack your corporate career, engineer a safe escape, and move toward more autonomy in life.  That call to action page for after reading will evolve to reflect my progress.
  • I have created a Facebook group for anyone willing to participate in the launch.  If you want to help, I would be much obliged!  Helping should prove pretty easy.  I’m looking for people, on launch day, to either purchase the book, leave me an Amazon review, or just spread the word via social media.  I’m already grateful for your visits to the site and reading of the blog, so no pressure at all.
  • If you want to see updates on the launch, I’ll probably keep you informed on my blog, but signing up for my mailing list or the Facebook group will ensure you receive updates when it goes live.
  • And one last thing.  I need your help picking a cover — please participate!

The Candidate Covers

One Last Thing

Oh, and if you want a sample of the book, you can do it by signing up for the mailing list using the form here.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)


Habits that Pay Off for Programmers

Editorial Note: I originally wrote this post for the LogEntries blog.

I would like to clarify something immediately with this post.  Its title does not contain the number 7, nor does it talk about effectiveness.  That was intentional.  I have no interest in trying to piggy-back on Stephen Covey’s book title to earn clicks, which would make this post a dime a dozen.

In fact, a google search of “good habits for programmers” yields just such an appropriation, and it also yields exactly the sorts of articles and posts that you might expect.  They have some number and they talk about what makes programmers good at programming.

But I’d like to focus on a slightly different angle today.  Rather than talk about what makes people better at programming, I’d like to talk about what makes programmers more marketable.  When I say, “habits that pay off,” I mean it literally.

Don’t get me wrong.  Becoming better at programming will certainly correlate with making more money as a programmer.  But this improvement can eventually suffer from diminishing marginal returns.  I’m talking today about practices that will yield the most bang for the buck when it comes time to ask for a raise or seek a new gig.

Read More


Taking the Guild Metaphor Too Far

Today, I’d like to talk about the pervasiveness of the craft guild metaphor in today’s software development landscape.  Specifically, I want to talk about how I think we’ve jumped the shark with this and how it now harms more than helps.  I recognize that I’m probably going to inspire some ire and get myself in trouble here, but please hear me out a bit.

First of all, some words of caveat.  I don’t say this from a place of any hostility or really even criticism.  In other words, I don’t take the position, “you’re all making a mistake with this and being silly.”  Rather, the more I wrote in Developer Hegemony, the more the guild metaphor came to feel wrong to me.  But only during the course of the last few days did I figure out how to articulate why.  So now, I post from the perspective of, “I think we recently took a slight wrong turn and that we should stop to reconnoiter a bit.”

Before I get to building my case, I want to spend some time applauding the guild metaphor for what I believe it has provided us.  I believe it important that I do so because it clarifies my position.  You can’t make a “wrong turn” without having started on the right track.

Also note that I don’t believe anyone has stated what I’m about to say as the reasoning for the metaphor.  What you will read next comes from inferences I have made.

Prequel to the Guild Metaphor: Drilling Holes in Sheet Metal

Corporate software development, by and large, got its start helping organizations capitalize on efficiency opportunities.  Some VP of something, looking at a typed spreadsheet, would say “if we could speed this process up by 25%, we could hit our third quarter numbers!  Poindexter, come in here and do that thing you do with the computer and make it so!”

Poindexter would then leave and come back a few days later.  “I flipped the bits and bypassed the mainframe and transmogrified the capacitor and –“

“In English, Poindexter!”

“Oh, right, sorry Mr. Rearden.  I was able to do a 30% speedup.”

“Good work, Poindexter!”

In this world, you had business people who would create strategy and delegate cost savings to geeks in bite sized morsels.  The geeks would diligently execute their tasks.

Because of this historical and ubiquitous communication deficit, the business people misunderstood the nature of geek work.  Their mental model of software development paralleled it to building construction and manufacturing.  The geeks occupied the role of line level laborers in their particular domain.  And so decades of horribly mismanaged software projects ensued.

“Come on, Poindexter, I need your codes for the next speedup by Friday or we won’t make our numbers!”

“But, Mr. Rearden, you don’t understand – it’s not that simple!  We can’t just – “

“Look, Poindexter, it’s not rocket science.  Just code faster and copy and paste the thing you did last time.  Think of yourself as a guy who drills holes in sheet metal, Poindexter.  Get a stronger drill bit, and lay the last sheet over the new one, using it as a template.  Do I have to think of everything?!”

“But, Mr. Rearden, it doesn’t work that – “

“Shut up Poindexter, or I’ll find a cheaper, offshore Poindexter!”

Read More


Logging for Fun: Things You’d Never Thought to Log

Editorial Note: I originally wrote this post for the LogEntries blog.

I work as a consultant in the software industry.  This work affords me the opportunity to see and interact with many different teams and thus to observe prevailing trends.  Among these teams, the attitude toward logging tends to be one of resigned diligence.

That is, many developers view application logging the way they view flossing their teeth: a necessary, dull maintenance activity that will pay dividends later.  Today, however, I’d like to encourage readers to consider a different side of logging.  In the right context and with the right intent, the activity can do so much more than simply insulate against audits and facilitate troubleshooting.  Logging can, in a sense, offer similar appeal to journaling or generally recording information for posterity.

Logging loosely consists of two components: recording and storing information.  As application developers, we find our thoughts occupied by the recording and how that affects our code.  We consider the storage and retrieval only inasmuch as it later aids our debugging efforts.  But we can expand the storage to include sophisticated aggregation, filtering, and querying techniques.  And in these techniques, we can find new ways to understand subjects that interest us.

To be a bit more concrete, I’m going to offer some examples in this post of worlds that you can open through logging.  But the examples will require you to view logging not as dumping data to some file, but as recording information in a way that you can mine it for meaning.  Obviously not all of us share the same interests.  But these examples may give you ideas for your own interests, even if they do not all appeal to you directly.

Read More