DaedTech

Stories about Software

By

Managing Risk via Static Analysis

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  While you’re there, take a look at the features of NDepend and download a trial, if you’re so inclined.

When software developer talk about static analysis, it’s often in the context of craft improvement.  Ask most developers in a group about static analysis tools and you’ll get a range of responses, many of which will be fueled by some degree of passion, resulting from past experience.  From here, the conversation will tend to dive into the weeds for any non-technical stakeholder that might be listening; if you’re not a programmer, you probably don’t have much of an opinion as to whether or not cyclomatic complexity of 5 is acceptable for a method.

As a result, static analysis tends to get pegged heavily as a purely a matter of shop.  The topic tends to be pretty opaque to management because developers present it to them in terms of “this will make us better and the code better.”  Management that trusts the developers will tend to agree to the purchase with a sentiment of, “okay, I’ll take your word for it.”  Management that is more skeptical says, “maybe next year if our numbers are good.”

I find this to be a shame because it’s a lost opportunity, even when management agrees.

Static analysis most certainly is a way for developers to improve their craft and their codebases.  But, in the hands of an architect or team lead that truly understands the business and works well with management, static analysis can be an excellent tool for managers, even if the use has to be a management-architect team effort.

How so?  Well, there are a lot of ways, but the one I’d like to mention today is risk management.  As the title would imply, managing risk tends to be the purview of people whose title is manager.  Sure, the developers have responsibility for this, but their primary charter is to build stuff — management exists specifically to engage in planning activities, including the crucial concern of risk management.

How does this work?  Well, I’ll show you, and I’ll do it by explaining the sort of highly technical things that static analysis could catch in highly non-technical and readable ways.  These are all going to be operational risks — static analysis can’t help you if you’re building the wrong product or badly under-staffing your projects.  But it can help you avoid landmines in your software.  If you’re a manager, allow me, for the moment, to serve as your “business-savvy architect.”

Architect

Read More

By

Calculating the ROI of NDepend

Editorial note: I originally wrote this post for the NDepend blog.  Head over to their site and check out the original.  While you’re there, take a look at the other posts and the offering to be had.

Years ago, I discovered NDepend and downloaded it for a trial.  At the time, I found myself working in a .NET shop where a lot of developers worked in the same large WPF codebase.  Code reviews were mandated, debates were frequent and impassioned, and global variables were everywhere, to the dismay of only some of us.  There was an entrenched majority that favored (or at least didn’t mind) a highly procedural style of writing object-oriented software, and nobody seemed able to put their fingers on why most feature development there had slowed to a crawl.

ScaryComputer

I was new to the group and had to pick my battles, particularly with people that had been there a long time.  Developers who favored automated testing and craftsmanship principles were in the minority there and had a history of leaving out of frustration, so I knew it’d be a challenge, and I went looking for help.  Among other things, I found NDepend and, after installing a trial, I recognized the power of the tool.

I recognized that it could help me as an objective, unbiased partner in making my arguments, but I also recognized that the way I approached code and architecture would never be the same.  The ability to visualize architecture in real time, the ability to treat code as queryable data, the metrics, the statistics, the well thought-out code warnings… it was a game-changer for me.  I just needed to convince my manager to let me spend a few hundred dollars to convert my trial version into a paid version.

It turned out this wasn’t hard, at least for me.  I had the good fortune of working for a company that appropriated a tools and learning budget for each individual developer, meaning all I had to do was declare that I wanted some of my total spend to go toward NDepend.  I did it without blinking.  But it might be that you aren’t as lucky.  Maybe you find yourself in a similar position to mine back then, but wanting to convince your manager that this powerful tool is indispensable because you don’t have a discretionary tools budget.

ROI: The Language of Management

I think I can help you here.  After all, I did leverage my experience running an IT department into a Plurlasight course about how to lobby your managers for practices and tools.  And the key to making a business case for anything, NDepend included, is to talk in terms of profits and losses, rather than in terms of, “it’s awesome, and it has all these graphs, and it shows me these rules, and CQLinq is the coolest thing ever, and…”  You get the idea.  NDepend’s coolness factor isn’t going to convince your manager to buy it for you.

Read More

By

Chasing Developer Productivity Metrics

I was listening to an episode of the “Western Devs” podcast on a plane the other night (I really like this podcast, by the way — give it a listen).  The subject of this particular show was the idea of developer productivity and the measurement thereof.  At the risk of playing spoiler, the discussion digressed in interesting fashion without necessarily taking a serious run at conclusions about these measurements.

But asking for a definitive measurement of developer productivity is a tall order.  I would actually even consider the attempt to be quixotic, though not for the reason alluded to early in the show (the idea that it might be categorically impossible to measure).  I think there are any number of ways, some even credible, to measure productivity for developers.  I think the trouble arises from the notion that they could be applied outside of a narrow context and also that it’s especially important how productive a developer is.

Let me return to that claim a little later, though.  First, I want to talk about The Organization.

What We Want from the Organization

It’s important, at this point, to dispense with the euphemisms. “Productivity,” in a business context, is a measure of efficiency, which is a comparative ability to deliver the same amount of stuff in less time (or for less money, though, in wage-land, time and money are like energy and matter in special relativity).  So productivity is really “worth” for labor.

Building the Pyramids

For developers, then, it becomes more personal.  Monetary worth is a bean counter distinction, and they don’t really know worth, we tell ourselves.  They don’t understand what Alice brings to the table when she goes around performing targeted refactorings that make everyone more productive, and they don’t recognize how important Bob is to the team’s morale, even if he doesn’t, himself, deliver a lot of code.

So we create situational, alternate definitions of productivity that reflect our ethos and emotional attachment to what we do.  We re-couch productivity as a way of describing the meritocracy that we feel ought to exist within the company.  And it is this very tendency that leads us to discuss endlessly “what does developer productivity even mean and how do we measure it?”  Our definitions are aspirational rather than practical.  We want an orderly world and we want the organizations for which we work to radiate fairness toward us.

But the organization has other ideas.  The organization provides individualized feedback on our productivity/efficiency (i.e. our performance) in the form of performance reviews.  And boy do we ever misunderstand these.

Read More

By

Career Advancement for the Low Price of Your Soul

When I was a kid, I remember my little brother watching Disney films pretty much constantly from the ages of probably 1 to 6 or so. As a result, I have an embarrassingly encyclopedic memory of the plots and songs of the movies from that specific time window. Probably at the epicenter of this Disney knowledge for me was the film, “The Little Mermaid” and I can remember that crazed chef chasing Sebastian the crab around and still giggle to this day. But of all of the songs in that movie, there’s only one that makes me think of the corporate world. I’ll come back to that.

Claw Back, Disney Style

There are a few standard perks in corporate America (and, I’m sure the world, though I’m only familiar with hiring in the USA). Health insurance is pretty much table stakes for serious employment these days, and with a decent employer contribution to boot. Paid time off is certainly up there, along with holidays and general human decency, one would hope.  There’s another tier that includes 401K contributions or some other retirement provision, perhaps a pension of some kind, things like life and disability insurance, and so on.  And, then, you start getting into a land more exotic where employers offer weird, unexpected stuff like “take your dog to work day” or sabbaticals or something.  One that usually shows up in this slightly more exotic realm is some concept of tuition reimbursement for employees that seek degrees or want to acquire skills through classes, certifications, etc.

This perk is a classic win-win situation.  The company invests in the career development of an employee and, in exchange, reaps the benefit of the employee’s learning and added skills.  The employee becomes more valuable to the organization by virtue of new knowledge and skills and, all other things being equal, will wind up earning more money over the course of a career.  What could be better than this arrangement?  Employees donate their spare time to improving themselves for their companies and companies donate money to the cause.  Sounds like a pretty good exchange of consideration.

And the company, really, just wants to help.  Advancing one’s skill set and education isn’t cheap, and there are so, so many poor unfortunates that just can’t afford it.  You know what?  I’ll let Ursula from the aforementioned Little Mermaid explain.

Poor unfortunate souls,
In pain, in need!
This one longing for more skills
That one wants a new degree
And do I help them?
Yes, indeed!

UrsulaContract

Read More