Stories about Software


Static Analysis Isn’t Just for Techies

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 a trial of NDepend and give it a spin.

I do a lot of work with and around static analysis tools.  Obviously, I write for this blog.  I also have a consulting practice that includes detailed codebase and team fact-finding missions, and I have employed static analysis aplenty when I’ve had run of the mill architect gigs.  Doing all of this, I’ve noticed that the practice gets a rap of being just for techies.

Beyond that even, people seem to perceive static analysis as the province of the uber-techie: architects, experts, and code statistics nerds.  Developing software is for people with bachelors’ degrees in programming, but static analysis is PhD-level stuff.  Static analysis nerds go off, dream up metrics, and roll them out for measurement of developers and codebases.

This characterization makes me sad — doubly so when I see something like test coverage or cyclomatic complexity being used as a cudgel to bonk programmers into certain, predictable behaviors.  At its core, static analysis is not about standards compliance or behavior modification, though it can be used for those things.  Static analysis is about something far more fundamental: furnishing data and information about the codebase (without running the code).  And wanting information about the code is clearly something everyone on or around the team is interested in.

To drive this point home, I’d like to cite some examples of less commonly known value propositions for static analysis within a software group.  Granted, all of these require a more indirect route than, “install the tool, see what warnings pop up,” but they’re all there for the realizing, if you’re so inclined.  One of the main reasons that static analysis can be so powerful is scale — tools can analyze 10 million lines of code in minutes, whereas a human would need months.

Read More


Journeyman Idealists Inside of Companies

In the last post in this series, I introduced the concept of a journeyman idealist.  This post represents a simple continuation of that one — part 2 of a 3 part series.

Before I dive in, though, I’d like to remind everyone that Monday, the 12th, is the last day to enter the giveaway for free expert beginner swag.  Go here and fill out the rafflecopter form for a chance to win free stuff.

The Job Interview

When it comes to the role of the journeyman idealist, we can start with the interview.  Let me first say that I think job interviews are stupid.  Full stop.  I don’t mean that they need work — I mean that you should take that baby and throw it out with the bathwater.

I go into a lot more detail in my book than I will here, but the history of the job interview is basically, “an aging, grouchy Thomas Edison pulled a random management fad that would have rejected Albert Einstein out of thin air.”  That’s actually the entire history.  No one has meaningfully change it since it debuted, except that now it can be equally stupid over Skype or Webex as the original. in-person flavor.  (Seriously, research this — your jaw will drop.)


Imagine if I channeled Thomas Edison today (and were brilliant enough to have that kind of global influence).  I declared that, henceforth, all marriage should take place via speed dating.  Want to get married?  Show up, meet 20 or so different people for 5 minutes each, then marry one at the end of the night.  Everyone leaves married!

Now, further imagine that people just did this for the next 100 years, without really questioning the practice’s merits.  And then imagine yourself, 100 years from now, observing the world.  Books have been written about how to ask all of the best questions in speed dating and to give all of the best answers.  They have titles like, “How to Radically Alter Your Appearance for 4 Minutes” and “Acing the Marriage Carousel.”  Wouldn’t you ask, “this is insane — why do we do this?”  And wouldn’t you feel bemused at the answer, “well, sure, it’s not ideal, but what other option is there?  No, we just need to improve the lighting in the room and work on acoustics so it’s fairer.”

The Journeyman Idealist Job Interview

Job interviews are silly across the board.  But we, in the software development industry, take this to unparalleled heights of absurdity.  To illustrate my point, I did some quick research.  I searched glassdoor for “{Profession} interview questions” and calculated what percentage of results on the first page constituted trivial minutiae/extreme detail shop talk.

  • Lawyer: 0%
  • Dentist: 0%
  • Speech Pathologist: 0%
  • Lab Technician: 10% (generously — the 1 positive response was just asking if the person had experience in “pipetting”)
  • Accountant: 20%
  • Economist: 20%
  • Statistician: 30%
  • Electrical Engineer: 50%
  • Network Engineer: 70%
  • Mechanical Engineer: 80%
  • Programmer: 90%
  • Software Engineer: 100%

Notice anything?  Other professions, it seems, assess mutual fit through the process via common conversation.  We do it with a game of Jeopardy.  Journeyman idealists absolutely drive this dynamic.  To them the job interview’s primary purpose is not to bring on needed staff, but to set all right in the industry by stack ranking according to merit.  (Or, as Google introspectively points out, “to make the interviewer feel smart.”)  And you don’t accomplish that with fluff like “how would you help this company make money?”

Programmer Roles

If you’ve ever tried to sort out why some of us have the title, “programmer” while others have “software engineer” and still others “developer,” you’ve no doubt stumbled across things like this.  And that’s before we started calling ourselves things like, well, journeyman or craftsman.  I picked the linked explanation post at random — seems well written enough.  Every post I’ve found like this follows the same basic pattern.  “Let’s acknowledge that these titles are probably interchangeable… but I just can’t help myself and I want to categorize.”  And so, unlike, say lawyers or mechanical engineers, we call ourselves a bunch of different things right out of the gate.


And then we get to the vertical ranking.  Of course, you’ve got to have Software Engineer I through VII.  And then after that you graduate to senior, principal, and then fellow engineer.  Or, wait.  Maybe senior, principal and fellow are actually V, VI, and VII, respectively.  Or is that Rocky?  And what about tech lead, team lead, and architect?  And does all of that apply to developer and programmer or just to software engineer?

My gosh, when your head stops spinning, you’ll realize that “make sense of all permutations of programmer titles in O(n^2) time” would make the perfect technical interview question.

The Virus of Rank

Look at how our infatuation with the illusion of meritocracy pervades and defines our industry.  We concern ourselves with trivia during job interviews.  We invent six job titles per week to give ourselves and then set about arguing how they compare to one another.  And, perhaps most interestingly of all, we do this for free, and we offer up insane amounts of surplus value in the process.

Consider software developer lifeline stackoverflow.  I cannot even begin to describe how grateful I am for all of the answers it has furnished me over the years.  But what motor drives that world (and gives rise to “coder competitions” and the like)?  Our curious obsession with stack-ranking ourselves.  Stack overflow offers this in the most naked form imaginable.

We go on to the site and spend dozens or hundreds of hours offering free labor that goes for more than $100 per hour on the market.  But we don’t do it for the points, and we don’t do it for the badges.  We do it for the rank and for socially proving our position in this imagined meritocracy.

I know, I know.  Many professions now have stack exchanges.  But which ones occupy the top ranks of traffic?  You don’t even have to look, do you?

I know, I know.  The cred you build up there has real market value during interviews.  Do the math and see if that holds up.  At a paltry 5 hours per week building rep over the course of 4 years, your labor’s market value would have been $100,000.  I sure hope that better job you secured because of your rep pays you at least $200,000 per year.

The Mechanics and Soul of Journeyman Idealism

Software developers do an impressive amount of collaboration and offer impressive amounts of free help.  A genuine “rising tide lifts all boats” spirit seems to underscore much of our industry and drive us to help one another (even if badges and points do nudge us in that direction).  So why does a merit-sorting obsession lurk just beneath the surface?

I offer you a simple and admittedly depressing answer.  Simply put, we labor intensely under the false belief that programming skill strongly correlates with business value and should correlate strongly with pay.  Reality simply does not support this, but let me return to that shortly, after I describe how this creates the journeyman idealist layer that haggles over titles, chases points, and conducts interviews.


Axiomatically, in our world, programming skill has a clear, directly proportional labor to value, which, in turn, equals pay.  In the interests of the broader meritocracy and owing to our notion that we can somehow objectively rank programming skill, we gnash our teeth at the notion that some impostor might occupy the wrong position and rank.  (I’m guilty of it myself.)

Unchecked, this drives us to think of money and status as a zero sum game in our industry, which is ludicrous given that demand for our labor far outpaces supply.  And yet, we believe it anyway.  And that makes us set up wage depressing games and sniping all on our own, with little intervention from opportunists or traditional idealists.

Programming Skill Has Diminishing Marginal Returns

Selling out.  This is how we generally thinking of the transition into management.  Or, perhaps more benevolently, “taking your hands away from the keyboard.”  You cash in a larger payday but get away from doing what you love.

As programmers, we like to reassure ourselves that we could totally do this anytime we want, but that we choose not to.  We also then make fun of the incompetents in the layers of management above us, all the while harboring smoldering righteous indignation that they should command higher salaries.  We do all of the real work.

But if you want to get even more miffed, consider that people with roles like “project manager,” “Scrum master,” “management consultant,” “agile coach,” “trainer” and more also command comparable or higher bill rates. These days, I mostly avoid doing app dev for a wage or a bill rate because it tends to pigeon-hole people into low bill rate roles.

I’ll stop beating around the bush.  Programming has a definite wage cap, and organizations pay more for all sorts of “peripheral” roles.  This probably causes some cognitive dissonance for many reading, but there you have it — programmers command some of the least money in the programming industry.

And it’s because getting better at programming only creates commensurate value to a point.  If I need some REST endpoint written in C#, I’d rather have Jon Skeet, with his legendary knowledge of the language, do it.  But not so much so that I’d pay more than a few extra dollars per hour.

We fetishize programmer skill to an almost comical degree.  That’s fine, and even fun, in a hobby context, but self-destructive when wages are at stake.

Chasing Value and Money

I once worked with a man, whose identity I will obfuscate to protect the guilty.  He had an idea for a website that he eventually paid someone to execute.  The idea?  More or less plagiarize some kind of fad diet and then charge people a subscription fee to do it.  All he needed was studio time to record a bunch of videos and then a custom web app to create a paywall.

When the time comes to hire an app dev vendor, people like this guy contact 4 or 5 vendors and then pick the second least expensive one.  But let’s say that money was no object and time was of the essence, and he picked the most expensive (and thus, presumably, best) one.  He could have hired the most rock-starrin’, 10-X-n’, algorithm-interview-acin’ developer on Earth, and he would have had a terrible, lawsuit inviting product delivered faster and in more maintainable packaging.  The real 10x developer would have been the one that managed to talk him out of this hair-brained scheme.

And that’s a simple example.  That scenario illustrates, with the least moving parts, that you simply cannot correlate programming skill with furnished value.  That plagiarist could have hired a journeyman idealist consultant to conduct interviews on his behalf, forcing people to implement alpha-beta pruning on white boards, and not writing any code would still have won the day.

Until Next Time

Editorial Note: I started this as a single post, but it wound up being about 5000 words — more than 3 times the size of a normal post.  So, I’ve turned it into a series.  This is part 2, and I’ve added part 3 to my posting schedule over the next few weeks.  You can stay tuned for that when it comes out.  Or, you can have the whole thing now.  Sign up for my mailing list below, and I’ll send you the full post as a PDF.  If you’ve already signed up and want the PDF, just go ahead and subscribe again.  I’ve tested it — you won’t be registered twice.

Subscribe to the Mailing List...

...and receive the rest of this post now, instead of waiting a few weeks for it to come up in my post rotation. (If you've already subscribed, just submit again to receive the post, but don't worry -- you won't be registered twice. I've tested that with my own email addresses.)


Preemptively Identifying Dead Seas

Today, I’m going to try to tie various strands of my life together into one lanyard of efficiency.  I haven’t done a reader question for a while, so I’ll change that today.  In this post, I’ll offer a terminology nod to dead seas, a now-defunct term that became one of my favorites.  The best context I can now offer lies here, in a post of mine, summarizing it.

A few months back, I made a post on NDepend called, “What to do When Your Colleague Creates Spaghetti Code.”  In this post, I described a caricature that I randomly named Bill, who you might recognize as sort of a quintessential expert beginner.  I subsequently received a reader question about this subject.

How can I tell if the company interviewing me has a “Bill?” (i.e. “How can I preemptively identify expert beginners?”)

Well, I’ll take a crack at that.

Expert Beginner Primordial Soup

I think that a meaningful examination of this question requires us to look at the conditions that give rise to such archetypes.  In the original series/book, I cover part of it.  The organization must draw sort of a neat little box around the techie group and then put an advanced beginner in charge.  From there, the concoction needs to simmer in a nicely insular environment, in which the budding expert beginner receives no real negative feedback, second guessing, or industry exposure.

But this assessment focuses entirely on the software development organization.  An ensconced expert beginner reigning over some miserable, backward fiefdom requires “the business” as an accomplice.  Simply put, it requires the operational laziness to allow your business to be ruled by an unaccountable “expert” operating with utter opacity.

Expert Beginner Hut

Imagine you started a pizza shop and hired a pizza chef to run the kitchen.  Then imagine that you completely delegated the cooking to the chef, as you should.  Life treats all of you well for a while and you develop some business.

But now complaints from customers start to come in about the taste and presentation of the pizza.  “My pizza was incredibly salty and all of the pepperoni was isolated to three slices!”  When you bring this problem to the chef, he tells you that such is life when it comes to making pizza—and, also, get out of the kitchen.  You don’t taste the pizzas coming out or look at them or launch any sort of investigation when his pizza chef assistants serially quit, muttering about his incompetence.  You just count the inbound trickles of revenue and assume that’s as good as it gets.

Read More


Expert Beginner Store Kickstarter (And Giveaway!)

Check it out: the Expert Beginner has a kickstarter page!  But before you go, if you’re interested in details and some free swag, read on.

The Expert Beginner is Getting a Store…Maybe

People seem to enjoy the Expert Beginner—well, the satire anyway.  I imagine they don’t enjoy the real life version, walking around and lecturing you about the proper use of their tortured frameworks.  Instead, we’re talking about this guy:

My wife and I (though, mainly her, and thanks to her for all of the hard work on this) have decided to see if people would be interested in adorning themselves or their offices (okay, who are we kidding, cubicles) with themed merchandise.

The goal of the Kickstarter campaign is to fund the creation and seeding of an online store that will sell this merchandise. The things we’re planning to stock the store with so far are sticker, mugs, and—best of all– extremely comfortable shirts.  Seriously, I actually wear mine on weekend flights, which means it’s pretty much the most comfortable thing I own.


If we’re funded, we can supply this merchandise indefinitely! If not, you might be on your own for making Expert Beginner shirts. (We promise not to sue you if we fall short and you want to pick up the torch.)

The campaign will end January 5th, but if you’d like to contribute, please don’t wait until then. Apparently, projects that gain a lot of interest in the beginning are more likely to be promoted and rank higher in searches on Kickstarter. We ask that you visit the page and donate now to jumpstart the campaign. If you’re one of the first to donate, you have the chance at some early bird rewards, including mugs and shirts given for lower donation amounts.

Again, here’s the link to visit the Kickstarter Campaign Now

There’s also a reward for a $150 donation where you can get not only all the merchandise offered but also an hour on the phone with me to talk about whatever you like. I get a lot of reader questions for the blog, and in general, about a variety of subjects.  With those, you’re sort of at the mercy of my natural posting cadence and attention span.  With this donation option, you have my undivided attention for an hour, which is even longer than the time I donate at startup office hours.

If you can’t donate any money, you can still help! Please consider sharing this blog post with your social networks by using the usual buttons at the end of the post.   And you can enter our giveaway by sharing with your network via Rafflecopter.

Read More


Rewrite or Refactor?

Editorial Note: I originally wrote this post for the NDepend blog.  You can find the original here, at their site.  While you’re there, take a look at some of the other posts and announcements.  

I’ve trod this path before in various incarnations, and I’ll do it again today.  After all, I can think of few topics in software development that draw as much debate as this one.  “We’ve got this app, and we want to know if we should refactor it or rewrite it.”

For what it’s worth, I answer this question for a living.  And I don’t mean that in the general sense that anyone in software must ponder the question.  I mean that CIOs, dev managers and boards of directors literally pay me to help them figure out whether to rewrite, retire, refactor, or rework an application.  I go in, gather evidence, mine the data and state my case about the recommended fate for the app.


Because of this vocation and because of my writing, people often ask my opinion on this topic.  Today, I yet again answer such a question.  “How do I know when to rewrite an app instead of just refactoring it?”  I’ll answer.  Sort of.  But, before I do, let’s briefly revisit some of my past opinions.

Getting the Terminology Right

Right now, you’re envisioning a binary decision about the fate of an application.  It’s old, tired, clunky and perhaps embarrassing.  Should you scrap it, write it off, and start over?  Or, should you power through, molding it into something more clean, modern, and adaptable.  Fine.  But, let’s first consider that the latter option does not constitute a “refactoring.”

A while back, I wrote a post called “Refactoring is a Development Technique, Not a Project.”  You can read the argument in its entirety, but I’ll summarize briefly here.  To “refactor” code is to restructure it without altering external behavior.  For instance, to take a large method and extract some of its code into another method.  But when you use “refactor” as an alternative to “rewrite,” you mean something else.

Let’s say that you have some kind of creaky old Webforms application with giant hunks of gnarly code and logic binding the GUI right to the database.  Worse yet, you’ve taken a dependency on some defunct payment processing library that prevents you from updating beyond .NET 2.0.  When you look at this and say, “should I refactor or rewrite,” you’re not saying “should I move code around inside this application or rewrite it?”  Rather, you’re saying, “should I give this thing a face lift or rewrite it?”

So let’s chase some precision in terms here.  Refactoring happens on an ongoing and relatively minor basis.  If you undertake something that constitutes a project, you’re changing the software.  You’re altering the way it interacts with the database, swapping out a dependency, updating your code to a new version of the framework, etc.  So from here forward, let’s call that a reworking of the application.

Read More