NDepend

Improve your .NET code quality with NDepend

architects and developers fighting

5 Reasons Architects and Developers Don’t Get Along

There’s a cute term for a blog post or article that advertises, in its title, a number of points of interest. For example, “9 Tips for Getting out of Debt,” as a title would quality. This is called a “listicle,” which is a conjoining of list and article into one word (though, for me, this somehow manages to evoke the vague image of someone licking an icicle).

This template is not normally my style, but I thought it might be fun to try it on and see how it goes. The topic about which I’d like to talk today is the various tension vectors for architects and developers and this seems, somehow, uniquely suited to the listicle format.

Where the developer role is pretty standard, the architect role is often vague in its definition and can vary widely from organization to organization. In some shops, the architect is just the longest tenured developer, whereas in others the architect is a specialized role that generates mountains of UML diagrams.

The ambiguity and variance, combined with the fact that architect is nominally ‘above’ developers, creates a breeding ground for interpersonal friction. While not always present, this is a common theme in the industry. So, I’d like to examine 5 reasons for strife between architects and developers.

Continue reading 5 Reasons Architects and Developers Don’t Get Along

up your code review game

Improve Your Code Review Game with NDepend

Code review is a subject with which I’m quite familiar.  I’m familiar first as a participant, both reviewing and being reviewed, but it goes deeper than that.  As an IT management consultant, I’ve advised on instituting and refining such processes and I actually write for SmartBear, whose products include Collaborator, a code review tool.  In spite of this, however, I’ve never written much about the intersection between NDepend and code review.  But I’d like to do so today.

I suppose it’s the nature of my own work that has made this topic less than foremost on my mind.  Over the last couple of years, I’ve done a lot of lone wolf, consultative code assessments for clients.  In essence, I take a codebase and its version history and use NDepend and other tools to perform an extensive analysis.  I also quietly apply some of the same practices to my own code that I use for example purposes.  But neither of these is collaborative because it’s been a while since I logged a lot of time in a collaborative delivery team environment.

But my situation being somewhat out of sync with industry norms does not, in any way, alter industry norms.  And the norm is that software development is generally a highly collaborative affair, and that most code review is happening in highly collaborative environments.  And NDepend is not just a way for lone wolves or pedants to do deep dives on code.  It really shines in the group setting.

NDepend Can Automate the Easy Stuff out of Code Review

When discussing code review, I’m often tempted to leave “automate what you can” for the end, since it’s a powerful point.  But, on the other hand, I also think it’s perhaps the first thing that you should go and do right out of the gate, so I’ll mention it here.  After all, automating the easily-automated frees humans up to focus on things that require human intervention.

It’s pretty likely that you have some kind of automation in process for enforcing coding standards.  And, if you don’t, get some in place.  You should not be wasting time at code review with, “you didn’t put an underscore in front of that field.”  That’s the sort of thing that a machine can easily figure out, and that many, many plugins will figure out for you.

The advantages here are many, but two quick ones bear mentioning here.  First is the time-savings that I’ve discussed, and second is the tightening of the feedback loop.  If a developer writes a line of code, forgetting that underscore, the code review may not happen for a week or more.  If there’s a tool in place creating warnings, preventing a commit, or generating a failed build, the feedback loop is much tighter between undesirable code and undesirable outcome.  This makes improvement more rapid, and it makes the source of the feedback an impartial machine instead of a (perceived) judgmental coworker.

Continue reading Improve Your Code Review Game with NDepend

Code Metric Visualization: Lines of Code and Code Coverage

One of the features of NDepend that we get a lot of positive feedback about is its data visualization, and it’s really no surprise. The code metric visualizations allow teams and managers to quickly see what is happening in their code base. With NDepend’s custom code metrics, developers can generate visual reports of what matters to facilitate teamwork as well as keep management in the loop.

We have written before about how a company can use NDepend’s visualizations as a sort of “radiator” to track changes in the source code over time. We also have examples of companies (such as Stago and Siemens Healthcare) using it to great effect in helping architects and developers communicate effectively.  This resulted in producing better quality end products while still meeting deadlines.

Not only is it very informative, but the treemap view is also pretty aesthetically pleasing. We wanted to show it off and at the same time give a glimpse of how NDepend has changed over the years. We are all about making your code beautiful and following best practices, so now you can see how well we follow our own rules. Continue reading Code Metric Visualization: Lines of Code and Code Coverage

The Power of CQLinq for Developers

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.

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!

Continue reading The Power of CQLinq for Developers

Let’s Build a Metric: Wrapping Up

In the penultimate post in the metrics series, I explained the reasoning for winding down this series.  I also talked about performing one last experiment.  Well, that last experiment is in the books, and I’m going to share the results here, today.  The idea was to see what progress so far looked like, when applied to real code bases.

Before we get to the results, let’s recap the (admittedly quite incomplete) experimental formula that we’ve arrived at thus far.

UpdatedTimeToComprehend

T is the time in seconds, and it is a function of p, the number of parameters; n, the number of logical lines of code; f, the number of class fields; and, g, the number of globals.  Let’s see how this stacks up to reality.

I picked the methods to look at basically just by poking around at random C# projects on GitHub.  I tried to look for methods that were not overly jargon intensive and that minimized the factors that are not accounted for by this formula.

Continue reading Let’s Build a Metric: Wrapping Up