Stories about Software


Static Analysis Issue Management Gets a Boost

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 the features in NDepend’s latest version.

Years ago, I led a team of software developers.  We owned an eclectic portfolio of software real estate.  It included some Winforms, Webforms, MVC, and even a bit of WPF sprinkled into the mix.  And, as with any eclectic neighborhood, the properties came in a variety of ages and states of repair.

Some of this code depended on a SQL Server database that had a, let’s just say, casual relationship with normalization.  Predictably, this caused maintenance struggles.  But, beyond that, it caused a credibility gap when we spoke to non-technical stakeholders.  “What do you mean you can’t give a definitive answer to how many sales we made last year?”  “Well,” I’d try to explain, “I can’t say for sure because the database doesn’t explicitly define the concept of a sale.”

Flummoxed by the mutual frustration, I tried something a bit different.  Since I couldn’t easily explain the casual, implied relationships in the database, I decided to do a show and tell.  First, I went out and found a static analyzer for database schema.  Then, I brought in some representative stakeholders and said, “watch this.”  With a flourish (okay, not really), I turned the analyzer loose on the schema.

While they didn’t grok my analogies, the tens of thousands of warnings and errors made an impression.  In fact, it sort of terrified them.  But this did bridge the credibility gap and show them that we all had some work to do.  Mission accomplished.

Static Analyzer Issues

I engaged in something of a relationship hack with my little ploy.  You see, I know how this static analyzer would behave because I know how all of them tend to behave.  They earn their keep by carpet bombing your codebase with violations and warnings.  Out of the box, they overwhelm, and then they leave it to you to dial it back.  Truly, you can take this behavior to the bank.

So I knew that this creaky database would trigger thousands upon thousands of violations.  And then I just sat back waiting for the “magic” to happen.

I mention all of this to paint a picture of how static analyzers typically regard the concept of “issue.”  All categories of severity and priority generally roll up into this catch-all term, and it then refers to the itemized list of everything.  Your codebase has issues and it has lots of them.  This is how the tool earns its mind share and keep — by proving how much it can surface, and then doing so.

Thus you might define the concept simply as “all that stuff the static analyzer finds.”

Read More


How to Evaluate Software Quality from the Outside In

Editorial note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, take a look at Prefix and Retrace, for all of your prod support needs.

In a sense, application code serves as the great organizational equalizer.  Large or small, complex or simple, enterprise or startup, all organizations with in-house software wrangle with similar issues.  Oh, don’t misunderstand.  I realize that some shops write web apps, others mobile apps, and still others hodgepodge line of business software.  But when you peel away domain, interaction, and delivery mechanism, software is, well, software.

And so I find myself having similar conversations with a wide variety of people, in a wide variety of organizations.  I should probably explain just a bit about myself.  I work as an independent IT management consultant.  But these days, I have a very specific specialty.  Companies call me to do custom static analysis on their codebases or application portfolios, and then to present the findings to leadership as the basis for important strategic decisions.

As a simple example, imagine a CIO contemplating the fate of a 10 year old Java codebase.  She might call me and ask, “should I evolve this to meet our upcoming needs, or would starting from scratch prove more cost effective in the long run.”  I would then do an assessment where I treated the code as data and quantified things like dependence on outdated libraries (as an over-simplified example).  From there, I’d present a quantitatively-driven recommendation.

So you can probably imagine how I might call code a great equalizer.  It may do different things, but it has common structural, underpinnings that I can quantify.  When I show up, it also has another commonality.  Something about it prompts the business to feel dissatisfied.  I only get calls when the business has experienced bad outcomes as measured by software quality from the outside in.

Read More


What is Real User Monitoring?

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 around at their assortment of monitoring solutions.

Perhaps you’ve heard the term “real user monitoring” in passing.  Our industry generates no shortage of buzzwords, many of the them vague and context dependent.  So you could be forgiven for scratching your head at this term.

Let’s go through it in some detail, in order to provide clarity.  But to do that, I’m going to walk you through the evolution of circumstance that created a demand for real user monitoring.  You can most easily understand a solution by first understanding the problem that it solves.

A Budding Entrepreneur’s Website

Let’s say that the entrepreneurial bug bites you.  You decide to build some kind of software as a service (SaaS) product.  Obviously, you need some time to build it and make it production ready, so you pick a target go-live date months from now.

But you know enough about marketing to know that you should start building hype now.  So, you put together a WordPress site and start a blog, looking to build a following.  Then, excited to get going, you make a series of post.

And then, nothing.  I mean, you didn’t expect to hit the top of Hacker News, but you expected… something.  No one comments on social media or emails you to congratulate you or anything at all.

Frustrated, you decide to add a commenting plugin and some social media share buttons.  This, you reason, will provide a lower friction means of offering feedback.  And still, absolutely nothing.  Now you begin to wonder if your host provider hasn’t played a cruel trick on you in which it only serves the site when you visit.

The Deafening Lack of Feedback

If perhaps it sounds like I empathize, that’s because I sincerely do.  Years and years ago when I started my first blog, I posted into the ether.  I had no idea if anyone read those early posts.  Of course, I was just having a good time putting my opinions out there and not trying to make a living, so I didn’t worry.  But nevertheless, I eventually felt frustrated.

The frustration arises from a lack of feedback.  You take some actions and then have no ability to see what affect they have.  Sure, you can see the post go live in your browser, but are you reaching anyone?  Has a single person read the post?  Or have thousands read the post and found it boring?  It’s like writing some code, but you’re required to hand it off to someone else to compile, run, and observe.  You feel blind.

Read More


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