Stories about Software


The Case for a Team Standard

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 CodeIt.Right and give it a try.

In professional contexts, I think that the word “standard” has two distinct flavors.  So when we talk about a “team standard” or a “coding standard,” the waters muddy a bit.  In this post, I’m going to make the case for a team standard.  But before I do, I think it important to discuss these flavors that I mention.  And keep in mind that we’re not talking dictionary definition as much as the feelings that the word evokes.

First, consider standard as “common.”  To understand what I mean, let’s talk cars.  If you go to buy a car, you can have an automatic transmission or a standard transmission.  Standard represents a weird naming choice for this distinction since (1) automatic transmissions dominate (at least in the US) and (2) “manual” or “stick-shift” offer much better descriptions.  But it’s called “standard” because of historical context.  Once upon a time, automatic was a new sort of upgrade, so the existing, default option became boringly known as “standard.”

In contrast, consider standard as “discerning.”  Most commonly you hear this in the context of having standards.  If some leering, creepy person suggested you go out on a date to a fast food restaurant, you might rejoin with, “ugh, no, I have standards.”

Now, take these common contexts for the word to the software team room.  When someone proposes coding standards, the two flavors make themselves plain in the team members’ reactions.  Some like the idea, and think, “it’s important to have standards and take pride in our work.”  Others hear, “check your creativity at the gate, because around here we write standard, default code.”

What I Mean by Standard

Now that I’ve drawn the appropriate distinction, I feel it appropriate to make my case.  When I talk about the importance of a standard, I speak with the second flavor of the word in mind.  I speak about the team looking at its code with a discerning attitude.  Not just any code can make it in here — we have standards.

These can take somewhat fluid forms, and I don’t mean to be prescriptive.  The sorts of standards that I like to see apply to design principles as much as possible and to cosmetic concerns only when they have to.

For example, “all non-GUI code should be test driven” and “methods with more than 20 lines should require a conversation to justify them” represent the sort of standards I like my teams to have.  They say, “we believe in TDD” and “we view long methods as code smells,” respectively.  In a way, they represent the coding ethos of the group.

On the other side of the fence lie prescriptions like, “all class fields shall be prepended with underscores” and “all methods shall be camel case.”  I consider such concerns cosmetic, since they concern appearance and not design or runtime behavior.  Cosmetic concerns are not important… unless they are.  If the team struggles to read code and becomes confused because of inconsistency, then such concerns become important.  If the occasional quirk presents no serious readability issues, then prescriptive declarations about it stifle more than they help.

Having standards for your team’s work product does not mean mandating total homogeneity.

Read More


Considering a Port to .NET Core? Use NDepend

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 latest version of NDepend, with extensive features around technical debt measurement.

An American colloquialism holds, “only two things are certain: death and taxes.”  If I had to appropriate that for the software industry, I might say that the two certainties are death and legacy code.  Inevitably, you have code that you have had for a while, and you want to do things with it.

Software architects typically find themselves tasked with such considerations.  Oh, sure, sometimes they get to pick techs and frameworks for greenfield development.  Sometimes they get to draw fancy diagrams and lay out plans.  But frequently, life charges them with the more mundane task of “figuring out how to make that creaky old application run on an iPhone.”  Okay, maybe it’s not quite that silly, but you get the idea.

If you earn a living as an architect in the .NET world, you have, no doubt, contemplated the impact of .NET Core on your application portfolio.  Even if you have no active plans to migrate, this evolution of .NET should inform your strategic decisions going forward.  But if you have use for deploying the framework along with your application or if you want to run on different operating systems, you’re going to need to port that legacy code.

I am, by no means, an expert in .NET Core.  Instead, my areas of specialty lie in code analysis, developer training, and IT management and strategy consulting.  I help dev teams create solutions economically.  And because of this, I can recognize the value of NDepend to a port from what I do know about .NET core.

Read More


Expert Beginners Rendered Obsolete

I got an awesome tweet at the Expert Beginner twitter account the other day.  Omer had one of those “wow, I can’t believe I never thought of this myself” ideas.

Yes, please.  Up until this point, I have run this account as a solo effort.  But I certainly have no exclusive claim to some of the world’s worst wisdom delivered with some of the world’s most confidence.

So I am now accepting submissions via twitter DM.  Please send them my way, and I will curate, catalog and queue.  As my work becomes increasingly remote and reclusive, I need all the fodder I can get for the account.

Speaking of Expert Beginners

In case you followed this blog only recently, I’m talking about a phenomenon that started with this post.  You know that one job you had once?  It lasted a year and a half, but seemed like 12.  It dragged because of the senior principal architect on the project.  Courtesy of random name generator, we’ll call him Dale.

Dale eschewed popular frameworks because he once wrote this combination ORM-MVC platform back in 2004 and, in his mind, it’s still chugging along nicely.  This framework set the world record for depth of inheritance hierarchy at 124, per your last count.  Every time you wanted to add a column to some table in a CRUD app, Dale would have to come over and perform open heart surgery at your desk while you tried to read XKCD on your phone without his notice.  But should you ever go off on your own and download something like an actual ORM, Dale would go completely nuclear.

In Dale, we have a classic Expert Beginner.  You put up with him for as long as you could before moving on to greener pastures, but you’re pretty sure he’s still there, jamming his tortured framework into some already-doomed CRUD app.

Dale will tell you what’s wrong with so-called professional ORMs.

Anyway, as I decided to throw the satirical account open to public suggestions, I began to contemplate this older concept of mine against the backdrop of some newer ones.  (Can you believe this dude is 5 years old, already?)

Expert Beginners and Developer Hegemony

Specifically, I started to think about how the relatively simple profile of the Expert Beginner has aged.  In the years between his birth on my blog and the recent completion of my book, Developer Hegemony, I’ve spent a lot of time and mileage consulting.  In particular, I have done a good bit of training and management consulting following a stint as a technical executive.  This has furnished me with the office politics equivalent of language immersion.

I began to wonder about the fate of the expert beginner in the world of developer hegemony that I foresee.  I mention him some in the book, kind of in passing.  But what will actually come of him?

Read More


Is Your Code Hard to Understand?

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

I’ve heard a bit of conventional wisdom in the software industry.  It holds that people will read a given line of code an order of magnitude more times than they’ll modify it.  Whether that wisdom results from a rigorous study or not, I do not know. But it certainly squares with my experience.  And it also seems to square with the experience of just about everyone else.

Accepting this wisdom as axiomatic, code readability becomes an important business concern.  If you optimize for ease of writing at the cost of ease of reading, your business will lose money.  Better to spend some extra time in writing your code to ensure that future readers have an easy go of it.  And easy for them means that they understand the code.

You know of obvious ways to promote reader understanding in code.  Don’t give variables cryptic names or names that cannot be pronounced.  Don’t write gigantic methods and classes.  Limit method parameters and local declarations.  Read through the code out loud to see if it seems clear.  These guidelines will bring you a long way toward readability.

But other, subtle concerns can also chip away at your code’s readability.  I’ll list some of these here, today.  These are generally C# specific, but some are more broadly applicable than that.  What all of them have in common is that they constitute sources of confusion for readers that may not seem immediately obvious.

Read More


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