DaedTech

Stories about Software

By

Entering the Zone of Pain

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, download NDepend and see if your code falls into the infamous Zone of Pain.

Years ago, when I first downloaded a trial of NDepend, I chuckled when I saw the “Abstractness vs. Instability” graph.  The concept itself does not amuse, obviously.  Rather, the labels for the corners of the graph provide the levity: “zone of uselessness” and “zone of pain.”

When you run NDepend analysis and reporting on your codebase, it generates this graph.  You can then see whether or not each of your assemblies falls within one of these two dubious zones.  No doubt people with NDepend experience can recall seeing a particularly hairy assembly depicted in the zone of pain and thinking, “I knew it!”

But whether you have experienced this or not, you should stop to consider what it means to enter the zone of pain.  The term amuses, but it also informs.  Yes, these assemblies will tend to annoy developers.  But they also create expensive, risky churn inside of your applications and raise the cost of ownership of the codebase.

Because this presents a real problem, let’s take a look at what, exactly, lands you in the zone of pain and how to recover.

Read More

By

How to Prioritize Bugs on Your To-Do List

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 around at NDepend and explore its new tech debt measurement features.

People frequently ask me questions about code quality.  People also frequently ask me questions about efficiency and productivity.  But it seems we rarely wind up talking about the two together.  How can you most efficiently improve quality via the fixing of bugs.  Or, more specifically, how should you prioritize the list of bugs that you have?

Let me be clear about something up front.  I’m not going to offer you some kind of grand unified scheme of bug prioritization.  If I tried, the attempt would come off as utterly quixotic.  Because software shops, roles, and offerings vary so widely, I cannot address every possible situation.

Instead, I will offer a few different philosophies of prioritization, leaving the execution mechanics up to you.  These should cover most common scenarios that software developers and project managers will encounter.

Maximizing Self Interest

I’ll lead with the scenario probably most common to software developers.  Stop me if this sounds familiar.  The first interaction point you have with a bug is receiving an email from Jira or TFS or Rally or whatever.  From there, you log in, read the details, and check the pre-assigned priority.  You check that because of the bug-fixing algorithm imposed on you by management: fix any priority 1 bugs, or, if you have none of those, any priority 2 bugs, and so on down the line.

In this world, bug fixing becomes a matter of looking after your own self interest.  Prioritizing your own to do list, consequently, becomes simple.  Management and the business have made the important, strategic decisions already and will evaluate you on the basis of quantity of defects fixed.  Thus you should prioritize the easiest to fix first, so that you fix as many as possible.

This may sound cynical to you, but I’m fine with that.  I have a fundamental distaste for the specialization obsession we have that separates fixing and prioritization.  Organizations that freeze technical people out of the strategic discussion of priority reap what they sow.  Robbed of the ability to act in the organization’s best interests, developers should act in their own.  Of course, I would prefer developers participate in the “how do we act in the company’s best interests” discussions.

Read More

By

Intro to T4 Templates: Generating Text in a Hurry

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, take a look at GhostDoc.  In addition to comment generation capabilities, you can also effortlessly produce help documentation.

Today, I’d like to tackle a subject that inspires ambivalence in me.  Specifically, I mean the subject of automated text generation (including a common, specific flavor: code generation).

If you haven’t encountered this before, consider a common example.  When you file->new->(console) project, Visual Studio generates a Program.cs file.  This file contains standard includes, a program class, and a public static void method called “Main.”  Conceptually, you just triggered text (and code) generation.

Many schemes exist for doing this.  Really, you just need a templating scheme and some kind of processing engine to make it happen.  Think of ASP MVC, for instance.  You write markup sprinkled with interpreted variables (i.e. Razor), and your controller object processes that and spits out pure HTML to return as the response.  PHP and other server side scripting constructs operate this way and so do code/text generators.

However, I’d like to narrow the focus to a specific case: T4 templates.  You can use this powerful construct to generate all manner of text.  But use discretion, because you can also use this powerful construct to make a huge mess.  I wrote a post about the potential perils some years back, but suffice it to say that you should take care not to automate and speed up copy and paste programming.  Make sure your case for use makes sense.

The Very Basics

With the obligatory disclaimer out of the way, let’s get down to brass tacks.  I’ll offer a lightning fast getting started primer.

Open some kind of playpen project in Visual Studio, and add a new item.  You can find the item in question under the “General” heading as “Text Template.”

newtexttemplate

Give it a name.  For instance, I called mine “sample” while writing this post.  Once you do that, you will see it show up in the root directory of your project as Sample.tt.  Here is the text that it contains.

<#@ template debug="false" hostspecific="false" language="C#" #>
<#@ assembly name="System.Core" #>
<#@ import namespace="System.Linq" #>
<#@ import namespace="System.Text" #>
<#@ import namespace="System.Collections.Generic" #>
<#@ output extension=".txt" #>

Save this file.  When you do so, Visual Studio will prompt you with a message about potentially harming your computer, so something must be happening behind the scenes, right?  Indeed, something has happened.  You have generated the output of the T4 generation process.  And you can see it by expanding the caret next to your Sample.tt file as shown here.

samplett

If you open the Sample.txt file, however, you will find it empty.  That’s because we haven’t done anything interesting yet.  Add a new line with the text “hello world” to the bottom of the Sample.tt file and then save.  (And feel free to get rid of that message about harming your computer by opting out, if you want).  You will now see a new Sample.txt file containing the words “hello world.”

Read More

By

The Opportunist’s Guide to Start Consulting (Abridged)

Given the recent launch of Developer Hegemony, I decided to address a reader question.  This question hits near and dear to my heart and to the subject matter of the book. I’m going to paraphrase for the sake of anonymity.  But, either way, it amounts to a question about how to start consulting.

But First, Some Housekeeping

Before I dive into that, though, I’d like to make offer some links.  If you want to hear and read more from me, I offer you the chance.  Check these out.

And now, back to your regularly scheduled post.

The Reader Question

Without additional preamble, I’ll offer up the (paraphrased) reader question.

I’m currently a developer, and want to transition to freelance consulting. But I’m not quite sure where to start.. Do you have any advice on that? How did you manage to start a consultancy business?

First of all, understand the dichotomy here.  He asks for my advice and he also asks how I did it.  I ask everyone reading to understand that these aren’t necessarily the same thing.  In other words, I can tell you exactly what I did, but that doesn’t mean I think you should do it in exactly that way.

Oh, don’t get me wrong.  I don’t think I made any horrible mistakes or anything like that.  But I kind of wandered my way through the experience, not entirely sure at the time what I wanted.  Unlike the reader asking the question, I never explicitly decided to become a freelance consultant.  In fact, I just had some free time and wanted some extra money.

Read More

By

Have You Seen the NDepend API?

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, download NDepend and give it a try.

If you’re familiar with NDepend, you’re probably familiar with the Visual Studio plugin, the out of the box metrics, the excellent visualization tools, and the iconic Zone of Uselessness/Zone of Pain chart.  These feel familiar to NDepend users and have likely found their way into the normal application development process.

NDepend has other features as well, however, some of which I do not necessarily hear discussed as frequently.  The NDepend API has membership in that “lesser known NDepend features club.”  Yes, that’s right — if you didn’t know this, NDepend has an API that you can use.

You may be familiar, as a user, with the NDepend power tools.  These include some pretty powerful capabilities, such as duplicate code detection, so it stands to reason that you may have played with them or even that you might routinely use them.  But what you may not realize is the power tools’ source code accompanies the installation of NDepend, and it furnishes a great series of examples on how to use the NDepend API.

NDepend’s API is contained in the DLLs that support the executable and plugin, so you needn’t do anything special to obtain it.  The NDepend website also treats the API as a first class citizen, providing detailed, excellent documentation.   With your NDepend installation, you can get up and running quickly with the API.

Probably the easiest way to introduce yourself is to open the source code for the power tools project and to add a power tool, or generally to modify that assembly.  If you want to create your own assembly to use the power tools, you can do that as well, though it is a bit more involved.  The purpose of this post is not to do a walk-through of setting up with the power tools, however, since that can be found here.  I will mention two things, however, that are worth bearing in mind as you get started.

  1. If you want to use the API outside of the installed project directory, there is additional setup overhead.  Because it leverages proprietary parts of NDepend under the covers, setup is more involved than just adding a DLL by reference.
  2. Because of point (1), if you want to create your own assembly outside of the NDepend project structure, be sure to follow the setup instructions exactly.

Read More