Stories about Software


Prediction Markets for Software Estimates

The ongoing kerfuffle over the “No Estimates” movement is surreal to me.  So before I get to prediction markets for software estimates, I’ll discuss the surreal a bit. Instead of attempting to describe it, which, I can only imagine, would be meta-surreal, I’ll make use of an allegory of sorts.

No Wedding Estimates

Imagine that wedding planners have long struggled with an important issue.  For years and years, their clients have asked them to help pick a date on which it would not rain so that they could have outdoor weddings.  And, for years and years, their predictions have been spotty at best, resulting in irate clients, wet formal wear, and general heartburn.

In all that time, wedding planners have pored over weather patterns and diligently studied farmers’ almanacs.  And yet, the predictions did not substantially improve.  It got so bad that a group of upstart wedding planners met one year in the mountains and authored a document called “The Contingency Manifesto.”  This resulted in an important advance in wedding planning for outdoor weddings: reserving a backup plan not dependent on the weather.


And yet, not all was fixed.  People still wanted outdoor weddings, and continued to be disappointed when it rained, contingency notwithstanding.  They still demanded wedding planners help them figure out months and months in advance whether or not it would rain on a particular day.  And, this is understandable after all — weddings are important.

Quite recently, a group of wedding planners emerged under the hashtag #NoOutdoorWeddings.  Their message was simple: “we can’t predict the weather, so have your wedding inside and stop whining.”  The message was, of course, music to the ears of frustrated wedding planners everywhere.  But some planners and most clients balked.  “How can you tell the clients not to have weddings outside?  They’re the ones paying, so it’s our obligation to facilitate their wishes!”

This schism, it seemed, was irreparable.  And surreal.

  • Why is it necessary for wedding planners all to agree?  Can’t the ones that don’t want to deal with weather contingency just not do it and the ones who want to can?
  • Why can’t people figure out that trying to predict a chaotic system like the weather is a fool’s errand?
  • Why would you ask a wedding planner to make a prediction that could easily be influenced by his own interest?
  • Frankly, if one person is dumb enough to ask another to predict the weather on a day 9 months from now, and the other person is dumb enough to do it, can’t we just agree that the two deserve each other and the inevitable lawsuit?

How Estimation Actually Works Today

Read More


Avoiding the Dreaded Experience Tuples

I went to monster.com today and discovered that it still exists.  I’m actually kind of chuckling as I type this, and for that I apologize.  I realize that I’m in a pretty fortunate position not to have to be looking for work in such a way, so I’m not trying to make light of anyone’s situation.  But, in all seriousness, if you’re a non-entry level developer and you’re perusing monster, you have much better options (and if you honestly think you don’t, drop me an email, and I’ll see what I can do to help you find work).

Anyway, I wasn’t looking at monster in the hopes of landing a Junior Full Stack Ninja role, but because of a reader question.  Here’s the question.

How do you successfully compete against experience while interviewing? Do you leverage education? Open Source involvement? What should I fall back on?

I recently tried to make the argument that experience may not be a good thing and rather an open mind is better since experience tends to bring along bad habits that are not correctable where an open mind is willing to adapt to the corporate policies/procedures that a company has. Needless to say, I wasn’t very successful and honestly it probably came off like I was being a smart ass. I just can’t stand people wanting 3-5 years of experience. Like 2.5 is not good enough, it really needs to be 3? If 2.5 is fine, why not 2? Why is that .5 so much greater than just 2? It seriously feels like I am 6 again telling everyone that I am 6 and 4 months old, not 6. I am so much older than 6…

(By the way, you can submit questions on the sidebar at the right, under “Ask Erik,” if you want to get my take on something — and please do!)

First of all, I love the way this is phrased.  It’s poignant as it makes the frustration palpable, and it aptly exposes the absurdity of this candidate-employer matching approach.  But beyond just liking the way this conundrum is described, I think it raises an important topic.

The reason this question prompted me to head over to monster.com is because I formed a hypothesis.  I hypothesized that if I went to a generic job site and did a search for a programmer gig, the very first one I found would consist of boilerplate (years, tech) tuples.  I’ll call these “experience tuples.”  Monster has top mindshare in my head under “generic job site,” so I cross my fingers that it still existed, typed in the URL, and was pleasantly surprised.  I then typed, “C# Software Engineer” and clicked on the very first link.  Here’s what I saw.

Read More


Modularity on My Honeymoon

If you hadn’t noticed, I’ve been gone for the last couple of weeks.  I got married and went on a honeymoon and left the blog on auto-pilot, with scheduled cross posts of things I’d written for other blogs.  I figured this was better than providing no content and hopefully the posts and social media announcements synced up closely enough that I didn’t look ridiculous.

During the trip, I didn’t think a whole lot about software, per se, but I gave occasional thought to what I might say upon my return.  I think really good bloggers make cool segues out of trips and experiences.  You know, like  “I was gazing up at the Eiffel Tower and I couldn’t help but think of Liskov’s Substitution Principle.”  I’m not that good, so I didn’t come up with anything like that.  I was in France and Monte Carlo, and I ate a lot of cheese, saw a lot of sites, drank a lot of wine and spent a lot of time reading.  None of that reminded me of code or software, really.

An Idiot (Me) Abroad

In fact, the only technical lessons I could relate were birthed from my own stupidity.  I brought my Mac Book pro along, but, incredibly, managed to forget its charger.  Upon arrival at our hotel in Paris, jet lagged, I dug the laptop out of the bag to charge and discovered that this would be quite impossible.  Suddenly, the Mac’s 90% charge was an ominous harbinger of computing scarcity.  I’d have to ration, what, like 3 or 4 hours of latpop usage for the entire trip? Read More


Managing to Avoid Cobras

Incentives are a funny thing.  Done well, they can spur your team to productivity and career-advancing, win-win situations.  Done not so well, they can create havoc.

As this point, I could offer up a dry explanation of the “law of unintended consequences,” but I’ll let Wikipedia do that.  Instead, I’ll tell you a quick story about something that came to be known as the “cobra effect.”  Snakes are clearly more interesting than laws.

In colonial India, the Brits in charge didn’t like the large number of venomous snakes that they encountered. So they did something that seems imminently sensible at first blush: they offered a bounty to locals for dead cobras.  At first, things went well.  Locals killed corbras, locals got their rewards, and the governing Brits saw a dip in cobra encounters.  But then the cobra encounters started to creep back up, even as the number of dead cobras turned in continued to climb.

Turns out, the locals had started breeding cobras specifically to turn them in and collect the reward.  Once the British government caught wind of this, they (predictably) terminated the reward program, and the erstwhile cobra breeders simply released the now-useless snakes. So the net result of this program turned out to be an increase in the cobras.  Ouch.

Beware of Cobras

When I tell you to beware of cobras, I’m not talking about looking out for snakes (though, clearly, if you live in an area with cobras, you should probably look out for them).  I’m talking about keeping an eye out for bad incentives.  For instance, if you’re managing a software department, do a thought exercise as to what might happen if you agreed to pay testers $5 extra for each bug they found and developers $5 extra for each bug they fixed.  At first, that probably seems like a good way to get them all to work a little extra and produce good results.  But, channeling the cobra example, can you spot what might go wrong?

This is the beginning of a post that I wrote for the NDepend blog.  Click here to read the rest of it.



Make the Complex Simple

For many years, I associated the concept of “making the complex simple” with teaching. And that’s certainly not wrong. We’re in an industry filled with complexity, both essential and accidental. To survive in this industry requires understanding essential complexity and eliminating accidental complexity, and novices struggle with this. As developers become self-sufficient, they figure out complexity reduction enough that they can mentor others in the concept. Once they get to the point of teaching concepts pretty seriously — giving conference talks, creating courses, coaching, etc. — it can definitely be said they’ve become good at “making the complex simple.”

Of course, it could also be said that the term applies to communications with non-technical stakeholders and not just teaching inexperienced developers. Think fast — how would you explain to the CIO who doesn’t have a programming background why you should stop delivering features for a couple of weeks in order to retrofit an IoC container onto your codebase? If you start saying things like “inject your dependencies” and “switch your database driver without recompiling,” you’re keeping the complex complex as the CIO stares blankly at you. Making it simple isn’t easy, is it?

To take complicated concepts and communicate them simply, with minimized loss of pertinent information, is a skill you could (and should) spend a lifetime improving. It requires overcoming the curse of knowledge, understanding your subject matter extensively, knowing your target audience’s world fairly well, being  adept at mapping concepts and creating analogies, communicating clearly and, oh yeah, often doing it all off the cuff. Piece of cake, right?

Hard though it may be, it’s a skill worth developing.

I originally wrote this post for John Sonmez’s site, Simple Programmer.  Click here to read the rest of my argument as to why you should develop this skill.