DaedTech

Stories about Software

By

BDD in .NET for Complete Initiates

Editorial Note: I originally wrote this post for the Infragistics blog.  You can check out the original here at their site.  Go on over there for content from me and a bunch of other authors as well.

It’s pretty likely that you’ve heard of behavior-driven development, or BDD.  Maybe it’s just in the context of buzzword fatigue and wondering “how many different approaches to software have acronyms that end with DD?”  Whatever your level of cynicism, or lack thereof, BDD is worth a look.

A lot of my work over the last few years has involved coaching and mentoring on the subject of writing clean code, and I often tell initially skeptical developers that they should be writing methods that BAs and managers could more or less read (in places pertaining to business logic, anyway).  This isn’t as far-fetched as it sounds.  Think of a bit of code that looked like this.

Would it really be such a stretch to imagine a non-technical person being able to look at this and understand what was happening? Take an order to be evaluated, look through each of its line items, and check to see if the product they contain is in stock. You don’t need to be a programmer to have an idea of what’s happening here.

BDD From 10,000 Feet

BDD in essence, is taking this idea and expanding upon it by making domain-oriented conversation a part of software acceptance.  Don’t worry about “how” just yet.  Suffice it to say that you and various non-technical stakeholders can sit down together and write tests, in plain English, that can be run to demonstrate that system requirements are being met.  That’s pretty powerful.

FigherJet

Read More

By

The Wrong Thing more Efficiently is Still the Wrong Thing

Editorial Note: I originally wrote this post for the Infragistics blog.  Go check out the original post on their site and take a look around while you’re there to see some of the other authors posting interesting things.

Let’s say that, like many folks, one of your first tasks each morning is dealing with your email. You arrive at the office, grab yourself a coffee, and settle in to complete this ubiquitous modern task.

Naturally, the first thing you do is open your inbox. Then you open each unread email, select all, and copy it. Next, you open a new instance of Visual Studio, create a console project, add a text file to it, and paste the email text into that text file. By the end of doing this, you have somewhere between 2 and 20 instances of Visual Studio running, depending on how many unread emails you have. At this point, you’re ready to read the emails, so you alt-tab among the VS instances, closing each one after you’ve read the email.

This system works well for you, but there are two major drawbacks. First of all, it’s a real hassle to have to create a new project and a text file manually, and then open the text file. It’d be awesome if there were a way that you could make Visual Studio do this for you. And secondly, all of those instances of Visual Studio have a tendency to cause your machine to thrash, and they sometimes just crash.

ScaryComputer

What to do? I’ll come back to that.

Read More

By

Your Old Language Version is Costing You Money

Editorial note: this post was originally written for the Infragistics blog, and you can read the original here.  Check it out on their site and read the rest of the stuff there, as well.

Imagine that you walk into a company, and take a stroll through the software department.  All around you, as far as the eye can see, developers toil away, staring into 17 inch CRT monitors.  What would you think of that?  Would you have to restrain yourself from jogging over to the HR department, enthusiastically, to apply for a job?  Or would you thank your lucky stars that you worked somewhere else?  I’m betting the latter.

One of the most penny wise, pound foolish strategies that a company can pursue is hiring a team of software developers, whose mean salary may be in the six figure range, and saving a few bucks by forcing them to do their work on obsolete hardware.  It’s foolish because the productivity lost by these expensive workers far outpaces the cost of updated computers and monitors.  Of course, this is pretty commonly known these days.  You don’t see or hear about nearly as many companies skimping too much on a second monitor or new machines for software developers.

PackagedComputer

And yet, it’s still fairly common to make developers use older versions of programming languages and frameworks.  Now, this isn’t a completely direct parallel.  Companies historically have let hardware age on developers’ desks mainly as a cost savings strategy, whereas continuing to work on a “stable” version of a language or framework is generally a risk minimization strategy; why port your code base to v-next when that could introduce bugs and it doesn’t matter to the users?  That’s a fair argument, but the thing is, when you pull back a level of abstraction, risk minimizing is, at its core, still about cost savings.  In a company, everything comes down to top line revenue minus bottom line cost. Read More

By

Let’s Build a Metric 3: Compositeness

Last time, I talked through a little bit of housekeeping on the way to creating a metric that would be, uniquely, ours.  Nevermind the fact that, under the hood, the metric is still lines of code.  It now has a promising name and is expressed in the units we want.  And, I think that’s okay.  There is a lot of functionality and ground to cover in NDepend, so a steady, measurable pace makes sense.

It’s time now to start thinking about the nature of the metric to be created here, which is essentially a measure of time.  That’s pretty ambitious because it contains two components: defining a composite metric (recall that this is a mathematical transform on measured properties) and then tying it an observed outcome via experimentation.  In this series, I’m not assuming that anyone reading has much advanced knowledge about static analysis and metrics, so let’s get you to the point where you grok a composite metric.  We’ll tackle the experimentation a little later.

A Look at a Composite Metric

I could walk you through creating a second query under the “My Metrics” group that we created, but I also want this to be an opportunity to explore NDepend’s rich feature set.  So instead of that, navigate to NDpened->Metric->Code Quality->Types with Poor Cohesion.

Metric3

When you do that, you’re going to see a metric much more complicated than the one we defined in the “Queries and Rules Edit” window.  Here’s the code for it, comments and all.

There’s a good bit to process here.  The CQLinq code here is inspecting Types and providing data on Types.  “Type” here means any class or struct in your code base (well, okay, in my code base), along with a warning if you see anything that matches.  And, what does matching mean?  Well, looking at the compound conditional statement, a type matches if it has “LCOM” greater than .8 or “LCOMHS” greater than .95 and it also has more than 10 fields and 10 methods.  So, to recap, poor cohesion means that there are a good number of fields, a good number of methods, and… something… for these acronyms.

LCOM stands for “Lack [of] Cohesion of Methods.”  If you look up cohesion in the dictionary, you’ll find the second definition particularly suited for this conversation: “cohering or tending to cohere; well-integrated; unified.”  We’d say that a type is “cohesive” if it is unified in purpose or, to borrow from the annals of clean code, if it conforms to the single responsibility principle.  To get a little more concrete, consider an extremely cohesive class.

This class is extremely cohesive.  It has one field and three methods, and every method in the class operates on the field.  Type cohesion might be described as “how close do you get to every method operating on every field?”

Now, here’s the crux of our challenge in defining a composite metric: how do you take that anecdotal, qualitative description, and put a number to it?  How do you get from “wow, Recipe is pretty cohesive” to 0.0?

I originally wrote this post for the NDepend blog.  Click here to read the rest and hear me talk about going from qualitative to quantitative.

 

By

Let’s Build a Metric 2: Getting the Units Right

This is a post originally written for the NDepend blog.  Go check it out there and see some other posts that are up as well.

Last time in this series, there was definitely some housekeeping to accomplish.  I laid the groundwork for the series by talking a bit of theory — what are code metrics and what is static analysis?  I also knocked out some more practical logistics such as taking you through how to get the code base I’m using as well as how to create and attach an NDepend project to it.  The culmination was the creation of our very own, tiny, and relatively useless code metric (useless since NDepend already provides the metric we ‘created’).

So, seems like a good next thing to do is make the metric useful, but there may be an interim step in there of at least making it original.  Let’s do that before we get to “useful.”  But even before that, I’m going to do a bit of housekeeping and tell you about the NDepend feature of managing the queries and rules in the Queries and Rules Explorer.

Group Housekeeping

Last time around, I created the “My Rules” group under “Samples of Custom rules.”  This was nice for illustrative purposes, but it’s not where I actually want it.  I want to bring it up on the same level as that, right after “Defining JustMyCode”.  To do that, you can simply drag it.  Dragging it will result in a black bar indicating where it will wind up:

Metrics2 (1)

Once I’ve finished, it’ll be parked where I want it, as shown below.  In the future, you can use this to move your groups around as you please.  It’s pretty intuitive. Read More