DaedTech

Stories about Software

By

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

By

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

By

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.)

By

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

By

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