DaedTech

Stories about Software

Sep
22

By

Put a Little NDepend in your Visual Studio

Category: .NET Tags: , |

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  If you like posts on the topics of static analysis and software architecture, check out the rest of the posts while you’re over there.

The software development world is filled with what I think of as “Coke-Pepsi” debates. This is how my brain categorizes debates over preference that are almost entirely subjective. There is no right or wrong answer to “is Coke or Pepsi better?” The answer is, “whichever one you like better.”

Examples abound in the software world. Should you use a heavyweight IDE or a lightweight text editor? Which OOP language is ‘the best?’ And, speaking of OOP, should you use an OOP language at all, or should you use a functional one? Pascal casing or camel? The list goes on, but these sorts of things generally boil down to the comfort and preferences of the person or team.

It would be tempting to paint NDepend Standalone versus NDepend’s Visual Studio plugin with this brush. And, while I think you could make a pretty legitimate case that this too, is simply a matter of preference, I’d like to do a thought exercise today in which I lobby in favor of the integration approach. In my opinion, there are enough advantages that I might be able to sneak this one out of the Coke-vs-Pepsi realm.

pepsi-v-coke1

What’s The Difference?

First of all, I should probably explain a bit more about the difference. NDepend standalone runs like any standard, windows desktop application. In order to use it, you’d launch it and use it to query your code base, run reports, visualize your architecture, etc. If you wanted to modify your code and use NDepend simultaneously, you would have two open Windows that you would alt-tab between.

As a plugin, NDepend runs as if it were a part of Visual Studio itself. Visual Studio has a plugin-supportive architecture that allows third party tool authors to write plugins that behave this way. To users of the plugins, the integration is totally seamless. So for all intents and purposes, NDepend’s Visual Studio plugin makes NDepend a first class part of Visual Studio. Thus everything you do with NDepend and your code all happens in the same place: Visual Studio.

Why Is This Better?

I’d imagine the first thing that occurs to you is the lack of needing to alternate between two windows. And I submit that this is, in fact, an advantage, though this advantage only scratches the surface. Logistically, there is less friction in use when you don’t need to constantly context switch between two windows. And, even if you prefer to separate the concerns out into multiple windows (say, if you have multiple monitors), you can still do this inside of Visual Studio.

Read More

Sep
13

By

The Biggest Mistake Static Analysis Prevents

Category: The Life of a Programmer Tags: , | 4 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  Take a look at NDepend while you’re there; if static analysis interests you in the .NET space, it’s a must-try.

As I’ve probably mentioned before, many of my clients pay me to come do assessments of their codebases, application portfolios and software practice.  And, as you can no doubt imagine, some of my sturdiest, trustiest tools in the tool chest for this work are various forms of static analysis.

Sometimes I go to client sites, by plane, train or automobile (okay, never by train).  Sometimes I just remote in.  Sometimes I do fancy write-ups.  Sometimes, I present my findings with spiffy slide decks.  And sometimes, I simply deliver a verbal report without fanfare.  The particulars vary, but what never varies is why I’m there.

Here’s a hint: I’m never there because the client wants to pay my rate to brag about how everything is great with their software.

Smelly computer

Where Does It All Go Wrong?

Given what I’m describing here, one might conclude that I’m some sort of code snob and that I am, at the very least, heavily judging everyone’s code.  And, while I’ll admit that every now and then I think, “the Daily WTF would love this,” mostly I’m not judging at all – just cataloging.  After all, I wasn’t sitting with you during the pre-release death march, nor was I the one thinking, “someone is literally screaming at me, so global variable it is.”

I earnestly tell developers at client sites that I don’t know that I’d have done a lot better walking a mile in their shoes.  What I do know is that I’d have, in my head, a clearer map from “global variable today” to “massive pain tomorrow” and be better able to articulate it to management.  But, on the whole, I’m like a home inspector checking out a home that was rented and subsequently trashed by a rock band; I’m writing up an assessment of the damage and not tsking their lifestyle.

But for my clients, I’m asked to do more than inspect and catalog – I also have to do root cause analysis and offer suggestions.  So, “maybe pass a house rule limiting renters to a single bottle of whiskey per night,” to return to the inspection metaphor.  And cataloging all of these has led me to be a veritable human encyclopedia of preventable software development mistakes.

I was contemplating some of these mistakes recently and asking myself, “which was the biggest one” and “which would have been the most preventable with even simple analysis in place?”  It was interesting to realize, after a while, that the clear answer was not at all what you’d expect.

Read More

Aug
16

By

The Power of CQLinq for Developers

Category: .NET Tags: , , | 2 Comments

Editorial Note: I originally wrote this post for the NDepend blog. Check out the original here, at their site.  While you’re there, have a look around at some of the other posts and subscribe to the RSS feed if you’d like a weekly post about static analysis.  

I can still remember my reaction to Linq when I was first exposed to it.  And I mean my very first reaction.  You’d think, as a connoisseur of the programming profession, it would have been, “wow, groundbreaking!”  But, really, it was, “wait, what?  Why?!”  I couldn’t fathom why we’d want to merge SQL queries with application languages.

Up until that point, a little after .NET 3.5 shipped, I’d done most of my programming in PHP, C++ and Java (and, if I’m being totally honest, a good bit of VB6 and VBA that I could never seem to escape).  I was new to C#, and, at that time, it didn’t seem much different than Java.  And, in all of these languages, there was a nice, established pattern.  Application languages were where you wrote loops and business logic and such, and parameterized SQL strings were where you defined how you’d query the database.  I’d just gotten to the point where ORMs were second nature.  And now, here was something weird.

But, I would quickly realize, here was something powerful.

Nascar

The object oriented languages that I mentioned (and whatever PHP is) are imperative languages.  This means that you’re giving the compiler/interpreter a step by step series of instructions on how to do something.  “For an integer i, start at zero, increment by one, continue if less than 10, and for each integer…”   SQL, on the other hand, is a declarative language.  You describe what you want, and let something else (e.g. the RDBMS server) sort out the details.  “I want all of the customer records where the customer’s city is ‘Chicago’ and the customer is less than 40 years old — you figure out how to do that and just give me the results.”

And now, all of a sudden, an object oriented language could be declarative.  I didn’t have to write loop boilerplate anymore!

Read More

Jul
8

By

The Case for the NDepend Dashboard Feature

Category: .NET Tags: , |

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original post here, at the site.  While you’re there, check out NDepend — it’s my go-to tool for the codebase assessments that I do as part of my consulting practice.

If you hang around agile circles long enough, you’re quite likely to hear the terms “big, visible chart” and “information radiator.”  I think both of these loosely originate from the general management concept that, to demonstrably improve something, you must first measure and track it.  A “big, visible chart” is information that an individual or team displays in, well, big and visible fashion.  An information radiator is more or less the same concept (I’m sure it’s possible for someone who is an 8th degree agile black belt to sharp-shoot this, but I think you’d be hard pressed to argue that this isn’t the gist).

Big, Visible Information Radiators

As perhaps the most ubiquitous example imaginable, consider the factory sign that proudly displays, “____ days since the last accident,” where, hopefully, the blank contains a large number.  A sign like this is far from a feel-good vanity metric; it actually alters behavior.  Imagine a factory where lots of accidents happen.  Line managers can call meetings and harp on the importance of safety, but probably to limited effect.  After all, the prospect of a floor incident is abstract, particularly for someone to whom it hasn’t ever happened.

But if you start putting a number on it, the concept becomes less abstract.  “Currently we have an incident every day, but we want to try to make it happen only once per month, and we’re going to keep track.”  Now, each incident means that the entire factory fails each and every day, and it does so visibly.  Incidents go from “someone else’s problem that you hear about anecdotally from time to time” to “the thing that’s making us fail visibly.”  And then you’ll find that doing nothing but making the number very visible will serve actually to alter behavior — people will be more careful so as not to be responsible for tanking the team’s metrics.

0 Days Since Last Accident

In the world of agile, the earliest and most common bit of information to see was the team’s card wall: which features were in progress, which were being tested, which were complete, and who was working on what.  This served double duty of creating public visibility/accountability and providing an answer to the project manager’s “whatcha doin?” without interruptions or mind-numbing status meetings.  But times and technologies progressed, resulting in other information being visible to the team at all times.

These days, it’s common to see a big television or monitor located near a team and displaying the status of the team’s code on the build machine.  Jenkins is a tool very commonly used to do this, and it will show you projects with red for failing and green for all good.  If you want to get creative, you can use home automation tech to have red or green lamps turn on and off.  For the team, this is a way of exposing broken builds as a deficiency and incenting team members to keep it in a consistently passing state.

Read More

May
17

By

Calculating the ROI of NDepend

Category: The Life of a Programmer Tags: , | 5 Comments

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

« Older Posts
Newer Posts »