Stories about Software


Pulling Your Team Through a Project Crunch

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 take it for a test drive.

Society dictates, for the most part, that childhood serves as a dress rehearsal for adulthood.  Sure, we go to school and learn to read, write, and ‘rithmetic, but we also learn life lessons.  And these lessons come during a time when we can learn mostly consequence-free.

During these formative years, pretty much all of us learn about procrastination.  More specifically, we learn that procrastination feels great.  But then, perhaps a week later, we learn that procrastination actually feels awful.  Our young brains learn a lesson about tradeoffs.  Despair.com captures this with a delightfully cynical aphorism: “hard work often pays off after time, but laziness always pays off now.”

The fact that we laugh at this indicates something interesting.  Whereas we learn most childhood lessons and internalize them (e.g. don’t touch a hot stove), we don’t learn all of them this way.  Procrastination falls into this latter category.  We learn its perils, but we do it anyway, for various reasons.

As someone in the software industry, I suspect you can appreciate this.  Even if you diligently get out in front of all of your work, your organization may not follow suit.  So I’m sure you’ve seen your fair share of so-called “crunch time” over the years.  Crunch time occurs when you put a disproportionate amount of effort right before an important milestone.  Kinda like waiting until the night before the due date to write a 10 page essay on To Kill a Mockingbird.

Today, I’d like to talk about surviving these crunches.  How can you navigate them to come out on the other end with your team’s morale intact?

Beware the Death March

For argument’s sake, I’ll draw a fine line.  Crunch time and the so-called “death march” can seem like the same thing, but I submit that they differ importantly.  Crunch time involves working hard in a spurt to succeed.  Death marches involve working hard indefinitely with a high probability of failing anyway.

The first step for pulling a team through a crunch is to ensure that you’re not instead dispatching them on a death march.  If your organization has the unfortunate habit of getting itself into death marches, you have serious problems on your hands that transcend the immediate future.  At an organization like this, I’d recommend looking for escape avenues and hinting to others that they might do the same.

If this sounds bad or like the height of disloyalty, I suggest a bit of perspective.  Your organization is about to ask you to burn yourself out on an indefinite timeline for something that will probably fail.  Unless you’re a masochist, what about that warrants your loyalty?

Read More


How to Use NDepend on a Team with Only One License

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 how NDepend can help make you a better programmer.

I remember my first exposure to NDepend.  Back then, I worked for a company that allocated software developers a budget for personal improvement.  Predictably, most people spent theirs on books, courses, and the like.  But not me.

You see, as soon as I discovered NDepend, I saw immense potential for my own career.  A static analyzer that helped with visualizations of the codebase?  This wouldn’t just help with code reviews.  It would actually make me better at software development.  I took that argument to my manager, and he agreed.  Next thing I knew, I had an officially licensed copy of NDepend.

While NDepend did, in fact, improve my chops, I don’t intend to create an entire post about that here.  Instead, I want to respond to an interesting question I heard recently.  In essence, “how can we get the most out of NDepend with only one license for the team?”  Having used my training budget to buy NDepend, I found myself in the position of having the sole license and wanting to spread the value.

In the years between then and now, NDepend has grown more feature rich.  Meanwhile, I’ve traveled all over the place and interacted with dozens of software groups, as both employee and consultant.  But the question and the conundrum remain relevant.  So today, I’ll offer some ideas on how to generate the most value for a team from only one NDepend license.

Some Ground Rules, First

Before I get into my suggestions, however, I’d like to pre-address some things that a sharpshooter reading the post might say.  In other words, it’s not that I failed to consider these things, but that I don’t want to speak to them.

First of all, please don’t comment about strategies for using the license for multiple people in violation of the spirit or letter of the licensing model.  Just as I wouldn’t bother to blog about how stealing cable is a cheaper alternative to paying for cable, I won’t talk about this subject either.

Secondly, I consider the build machine edition of NDepend a separate discussion.  When you have only that version, you have something intended to be unique.  You can use the build machine edition by, well, installing it on the team’s build machine.

And, finally, the one person with the license could, obviously, hoard all of the benefit.  But, let’s assume that the team has a non-dysfunctional dynamic and wants to succeed as a group.

So with all that in mind, let’s move on to some creative use cases.

Read More


Software Monitoring: The Things that Might Interest You

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at the different sorts of production concerns that you can keep an eye on with their offering, some of which I address in this post.

If you have responsibility for software in production, I bet you’d like to know more about it.  I don’t mean that you’d like an extra peek into the bowels of the source code or to understand its philosophical place in the universe.  Rather, I bet you’d like to know more about how it behaves in the wild.

After all, from this opaque vantage point comes the overwhelming majority of maddening defects.  “But it doesn’t do that in our environment,” you cry.  “How can we even begin to track down a user report of, ‘sometimes that button doesn’t work right?'”

To combat this situation we have, since programmer time immemorial, turned to the log file.  In that file, we find answers.  Except, we find them the way an archaeologist finds answers about ancient civilizations.  We assemble cryptic, incomplete fragments and try to use them to deduce what happened long after the fact.  Better than nothing, but not great.

Because of the incompleteness and the lag, we seek other solutions.  With the rise in sophistication of tooling and the growth of the DevOps movement, we close the timing gap via monitoring.  Rather than wait for a user to report an error and asking for a log file, we get out in front of the matter.  When something flies off the rails, our monitoring tools quickly alert us, and we begin triage immediately.

Common Monitoring Use Cases

Later in this post, I will get imaginative.  In writing this, I intend to expose you to some less common monitoring ideas that you might at least contemplate, if not outright implement.  But for now, let’s consider some relative blue chip monitoring scenarios.  These will transcend even the basic nature of the application and apply equally well to web, mobile, or desktop apps.

Monitis offers a huge variety of monitoring services, as the name implies.  You can get your bearings about the full offering here.  This means that if you want to do it, you can probably find an offering of theirs to do it, unless you’re really out there.  Then you might want to supplement their offering with some customized functionality for your own situation.

But let’s say you’d just signed up for the service and wanted to test drive it.  I can think of nothing simpler than “is this thing on?”  Wherever it runs, you’d love some information about whether it runs when it should.  On top of that, you’d probably also like to know whether it dies unexpectedly and ignobly.  When your app crashes embarrassingly, you want to know about it.

Once you’ve buttoned up the real basics, you might start to monitor for somewhat more nuanced situations.  Does your code gobble up too many hardware resources, causing poor experience or added expense?  Does it interact with services or databases that fail or go offline?  In short, does your application wobble into sub-optimal states?

But what if we look beyond those basics?  Let’s explore some things you may never have contemplated monitoring about your software.

Read More


What DevOps Means for Static Analysis

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, have a look at NDepend’s static analysis offering.

For most of my career, software development has, in a very specific way, resembled mailing a letter.  You write the thing, and then you go through the standard mail piece rigmarole.  This involves putting it into an envelope, addressing the envelope, putting a stamp on, it and then walking it over to the mailbox.  From there, you stuff it into the mailbox.

At this point, you might as well have dropped the thing into some kind of rip in space-time for all you understand what comes next.  Off it goes into the ether, and you hope that it arrives at its destination through some kind of logistical magic.  So it has generally gone with software.

We design it, architect, and lovingly write it.  We package it up, test it, correct defects in it, and then we call it done.  From there, we fire it into the mailbox-black-hole of the software world: operations.  They take it and deploy it, or whatever, and then, by some magic we don’t concern ourselves about, it runs in the real world.  Or so it has generally gone.

Problems with the Traditional Approach

With the benefit of hindsight, you can probably guess the main problem with this state of affairs.  So rather than enumerate it dryly in a series of bullet points, let me offer it up in story format.

You work as an application developer in some very large enterprise.  There, you build web apps.  And you take pride in your work.  You write clean code, you maintain the unit test suite, you collaborate dutifully with QA, and you generally do your best.

In fact, this effort even extends beyond your own dev environment and into as many environment as you can see.  You run load, smoke, and integration tests in QA and sandbox environment.  And, as a whole unit, your team does everything it can to ensure the integrity of the work.  But beyond the pre-prod environment, the fate of your application becomes an utter mystery.  Some group of folks located in a different timezone take it from there.  You wish it well as it heads to production.

And then, one day, six months later, you get some incident report.  Apparently, some guy in Hungary or somewhere was doing something when somehow he get a null reference exception.  But don’t worry, here’s a brief description of what he said and a few thousand lines of some random log file.  Good luck with your repro!

Read More


From Employable Generalist to Successful Efficiencer

For regular followers, I bet you thought I forgot about reader question Fridays last week.  I didn’t.  Friday is a relatively low traffic day for bloggers, so I’ve decided to switch over to reader question Monday.  But, on Sunday night, I did forget about the post draft, so the first reader question Monday is actually Tuesday’s post.  I know.  I’m a little disoriented too.  But we’ll figure it out.

About a year ago, I wrote a post about niching down.  I asked readers to imagine if, instead of listing the services that they provided, housing contractors described the number of years they’d spent using their tools.  “I have 6 years of hammer, 3 years of reciprocating saw, etc.”  From that, they left it up to you to figure out if you could translate those skill into something useful, like fixing your garage door.  That’s us, in the software development world.  “Here are my experience tuples, and now I just need some kind of manager to figure out how to turn me into a useful resource.”

Given my tone, you can probably infer that I advise against this approach.  In fact, I frequently suggest specializing and figuring out how to solve business problems.  But as a few people have now pointed out via reader questions, I’ve not offered a lot in the way of advice to bridge the gap.   A reader in the Developer Hegemony Facebook group put it quite succinctly, in the parlance of my old post.

How do you translate 3 years C#, 6 years C++, etc… into “I can fix your garage”?

It’s a good question.

Read More