Stories about Software


Improving .NET Application Performance

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at the application monitoring options you can take advantage of.

First of all, make sure that you use StringBuilder when concatenating strings.  You see, the “+” operator — just kidding.  I mean, that’s not bad advice.  Rather, I’m kidding in that I just don’t want to offer this style of tip today.

Often, advice about application performance comes at you with the staccato of rapid fire tips.  “37 Ways to Shave Nanoseconds off of Your Overnight ETL Process.”  I exaggerate for comedic effect with that title, perhaps.  But the point remains.  Authors serve up advice for optimization with many tips that matter only inside of tight loops.  And it’s hard to keep all of those in your head.

I’d like to take a different tack here today and offer fewer suggestions in the hope that they’ll stick with you.  But I differentiate my message in another crucial way as well. I want to offer performance tips for .NET programming that will also help you write clean, readable code.

All too often, these concepts stand in opposition to one another.  Performance tips often demand changes that produce the desired effect while making the code harder to read.  This phenomenon gives rise to the iconic wisdom that “premature optimization is the root of all evil.”  Implementing them might bring relatively insignificant marginal gains in performance while creating confusing, hard-to-read code.

But it strikes me that readable and performant sometimes overlap.  And, since tips for that serve two purposes, they are definitely worth filing away.

Read More


Generate Documentation from Your Build

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 GhostDoc.

Before I get down to the brass tacks of how to do some interesting stuff, I’m going to spin a tale of woe.  Well, I might have phrased that a little strongly.  Call it a tale of corporate drudgery.

In any case, many years ago I worked briefly in a little department, at a little company that seemed to be a corporate drudgery factory.  Oh, the place and people weren’t terrible.  But the work consisted of, well, drudgery.  We ‘consulted’ in the sense that we cranked out software for other companies, for pay.  Our software plumbed the lines of business between client CRMs and ERPs or whatever.  We would write the software, then finish the software, then hand the software over, source code and all.

Naturally, commenting our code and compliance with the coding standard attained crucial importance.  Why?  Well, no practical reason.  It was just that clients would see this code.  So it needed to look professional.  Or something.  Didn’t matter what the comments said.  Didn’t matter if the standard made sense.  Compliance earned you a gold star and a move onto the next project.

As I surveyed the scene surrounding me, I observed a mountain of vacuous comments and dirty, but uniform code.

My Complex Relationship with Code Comments

My brief stay with (and departure from) this organization coincided with my growing awareness of the Software Craftsmanship movement.  Even as they copy and pasted their way toward deadlines and wrote comments announcing that while(x < 6) would proceed while x was less than 6, I became interested in the idea of self-documenting code.

Up to that point, I had diligently commented each method, file, and type I encountered.  In this regard, I looked out for fellow and future programmers.  But after one too many occasions of watching my own comments turn into lies when someone changed the code without changing the comments, I gave up.  I stopped commenting my code, focusing entirely on extractions, refactoring, and making my code as legible as possible.

I achieved an equilibrium of sorts.  In this fashion, I did less work and stopped seeing my comments become nasty little fibs.  But a single, non-subtle flaw remained in this absolutist approach.  What about documentation of a public (or internal) API?

Naturally, I tried to apply the craftsmanship-oriented reasoning unilaterally.  Just make the public API so discoverable as to render the issue moot.  But that never totally satisfied me because I still liked my handy help screens and Intellisense info when consuming others’ code.

And so I came to view XML doc comments on public methods as an exception.  These, after all, did not represent “comments.”  They came packaged with your deliverables as your product.  And I remain comfortable with that take today.

Read More


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


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


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