DaedTech

Stories about Software

By

How to Perform Effective Team Code Reviews

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, check out all of the new tech debt-related features in the newest version of NDepend.

I’ve heard people say (paraphrased) that teams succeed uniformly, but fail each in its own unique way.  While I might argue the veracity of this statement, it evokes an interesting image.  Many roads, lined with many decisions, lead to many different sorts of failures.

Code review presents no exception.  Teams can fail at code review in myriad, unique ways.  And, on top of that, many paths to broader failure can involve poor code reviews (doubtless among other things).

How can I assign such importance to the code review?  After all, many would consider this an ancillary team activity and one with only upside.  Done poorly, code review catches no defects.  Done well, it catches some defects.  Right?

How Code Review Can Go Wrong

Simply put, code review can have worse than zero effect.  Ineffectual code review suffers mainly the opportunity cost of the participants’ time.  But toxic code review creates morale problems, counterproductive team dynamics, and damaging distractions.

So the first order of business is to avoid a net negative effect.  To do this, one simply has to remove the potential of toxic culture from the process of code review.  Of course, that’s a bit easier said than done, but a lot of it just means following basic rules of human decency.  Start by treating one another with respect.  Then ensure that all participants feel comfortable getting and receiving feedback.  Enlist the help of even-tempered, charismatic folks to lead by example.

Once you’ve insulated yourself against the most damaging effects, it’s time to guard against ineffectual code reviews.  It is toward that end that I’ll be focusing for the remainder of this post.  Ineffectual code reviews can ways time, as I mentioned earlier.  But they can also create a false sense of security and lead to poor choices.

So what makes code review effective?  How can your team get the most out of this activity?  I’ll offer some thoughts based on firsthand experience across a wide number of organizations.

Read More

By

Considering a Port to .NET Core? Use NDepend

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 latest version of NDepend, with extensive features around technical debt measurement.

An American colloquialism holds, “only two things are certain: death and taxes.”  If I had to appropriate that for the software industry, I might say that the two certainties are death and legacy code.  Inevitably, you have code that you have had for a while, and you want to do things with it.

Software architects typically find themselves tasked with such considerations.  Oh, sure, sometimes they get to pick techs and frameworks for greenfield development.  Sometimes they get to draw fancy diagrams and lay out plans.  But frequently, life charges them with the more mundane task of “figuring out how to make that creaky old application run on an iPhone.”  Okay, maybe it’s not quite that silly, but you get the idea.

If you earn a living as an architect in the .NET world, you have, no doubt, contemplated the impact of .NET Core on your application portfolio.  Even if you have no active plans to migrate, this evolution of .NET should inform your strategic decisions going forward.  But if you have use for deploying the framework along with your application or if you want to run on different operating systems, you’re going to need to port that legacy code.

I am, by no means, an expert in .NET Core.  Instead, my areas of specialty lie in code analysis, developer training, and IT management and strategy consulting.  I help dev teams create solutions economically.  And because of this, I can recognize the value of NDepend to a port from what I do know about .NET core.

Read More

By

Is Your Code Hard to Understand?

Editorial Note: I originally wrote this post for the Infragistics blog.

I’ve heard a bit of conventional wisdom in the software industry.  It holds that people will read a given line of code an order of magnitude more times than they’ll modify it.  Whether that wisdom results from a rigorous study or not, I do not know. But it certainly squares with my experience.  And it also seems to square with the experience of just about everyone else.

Accepting this wisdom as axiomatic, code readability becomes an important business concern.  If you optimize for ease of writing at the cost of ease of reading, your business will lose money.  Better to spend some extra time in writing your code to ensure that future readers have an easy go of it.  And easy for them means that they understand the code.

You know of obvious ways to promote reader understanding in code.  Don’t give variables cryptic names or names that cannot be pronounced.  Don’t write gigantic methods and classes.  Limit method parameters and local declarations.  Read through the code out loud to see if it seems clear.  These guidelines will bring you a long way toward readability.

But other, subtle concerns can also chip away at your code’s readability.  I’ll list some of these here, today.  These are generally C# specific, but some are more broadly applicable than that.  What all of them have in common is that they constitute sources of confusion for readers that may not seem immediately obvious.

Read More

By

Keep Your Codebase Fit with Trend Metrics

Editorial Note: Thanks to everyone who voted for a Developer Hegemony Cover.  I’ll tabulate the official results soon, but it looks like the dark cover is the clear favorite!

Second 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 new version of NDepend.

A while back, I wrote a post about the importance of trends when discussing code metrics.  Metrics have impact when teams are first exposed to them, but that tends to fade with time.  Context and trend monitoring create and sustain a sense of urgency.

To understand what I mean, imagine a person aware that he has put on some weight over the years.  One day, he steps on a scale, and realizes that he’s much heavier than previously thought.  That induces a moment of shock and, no doubt, grand plans for gyms, diets, and lifestyle adjustments.  But, as time passes, his attitude may shift to one in which the new, heavier weight defines his self-conception.  The weight metric loses its impact.

To avoid this, he needs to continue measuring himself.  He may see himself gaining further weight, poking a hole in the illusion that he has evened out.  Or, conversely, he may see that small adjustments have helped him lose weight, and be encouraged to continue with those adjustments.  In either case, his ongoing conception of progress, more than the actual weight metric, drives and motivates behaviors.

The same holds true with codebases and keeping them clean.  All too often, I see organizations run some sort of static analysis or linting tool on their codebase, and conclude “it’s bad.”  They resolve only to do a better job in a year or two, when the rewrite will start.  However good or bad any given figure might be, the trend-line, and not the figure itself, holds the most significance.

Trend Metrics with NDepend

In that last post, I touched only on the topic, but not the specifics.  Here, I’d like to speak to how NDepend helps you with metrics.  I suspect that a lot of people know NDepend for its memorable visualization aids and its code rules and queries.  I don’t see as much discussion about the valuable trend tools, perhaps because they were release comparably recently.  In either case, I want to talk today about those tools.

Read More

By

Some Visual Studio Tips and Tricks

Editorial Note: I originally wrote this post for the SmartBear blog.  

Last month, I wrote a post about integrated development environments (IDEs).  As mentioned in that post, developers commonly debate the relative merits of lightweight text editors against heavyweight IDEs.  But I suspect just about everyone can agree that if you do plan to use an IDE, you should maximize its utility.  In other words, as long as you’re incurring the overhead, you should reap the benefits.

I work a great deal in the .NET space, which means that I spend a good bit of time using Visual Studio, an extremely heavyweight IDE.  In the interests of full disclosure, I will admit to loving to work with Visual Studio.  But that love has grown out of years of exploring it, tinkering with it, and learning to maximize my efficiency with it.  If not for all that, it would seem only a glorified text editor that takes a lot longer than Notepad++ or Sublime to start.

Today, I’d like to offer some suggestions for getting more mileage out of Visual Studio.  By no means is this an exhaustive list; that would require books and books, rather than a single blog post.  Visual Studio has tons of capability.  Rather, today, I’ll offer some tips and tricks you might not have seen previously.

Read More