DaedTech

Stories about Software

By

Are Code Rules Meant to Be Broken?

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 NDepend’s code rules.  Interested in me writing for your site?  Get in touch through our content marketing business.

If you’ve never seen the movie Footloose, I can’t honestly say I recommend it.  If your tastes run similarly to mine, you’ll find it somewhat over the top.

A boy from the big city moves to a quiet country town.  Once there, he finds that the town council, filled with local curmudgeons, has outlawed rock music and dancing.  So follows a predictable sequence of events as the boy tries to win his new town over and to convince them of the importance of free expression.  You can probably hear his voice saying, “come on, Mr. Uptighterton, rules are made to be broken!”

Today, I’d like to explore a bit the theme of rules and breaking them.  But I’ll move it from a boy teaching the people from American Gothic to dance and into the software development shop and to rules around a codebase.

Perhaps you’ve experienced something similarly, comically oppressive in your travels.  A power mad architect with a crazy inheritance framework.  A team lead that lectures endlessly about the finer points of Hungarian notation.  Maybe you’ve wanted to grab your fellow team members by the shirt collars, shake them, and shout, “go on, leave the trailing underscore off the class field name!”

If so, then I sympathize and empathize.  Soul crushing shops do exist, seeking to break the spirits of all working there.  In such places, rule breaking might help if only to shake people out of learned helplessness and depression.  But I’m going to examine some relatively normal situations and explore the role of rules for a software team.

Read More

By

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

By

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

By

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

By

CodeIt.Right Rules Explained, Part 4

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, have a look at CodeIt.Right to help you perform automated code reviews.  

Today, I’ll do another installment of the CodeIt.Right Rules, Explained series.  I have now made four such posts in this series.  And, as always, I’ll start off by citing my two personal rules about static analysis guidance.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I’m playing rhetorical games here.  After all, I could simply say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestion.

In that spirit, I’m going to offer up explanations for three more CodeIt.Right rules today.

Read More