DaedTech

Stories about Software

Jun
21

By

Exploring the Tech Debt In Your Codebase

Category: .NET Tags: , , |

Editorial note: I originally wrote this for the NDepend blog.  You can check out the original here, at their site.  While you’re there, check out the tech debt features in the newest version of NDepend.

Recently, I posted about how the new version of NDepend lets you compute tech debt.  In that post, I learned that I had earned a “B” out of the box.  With 40 minutes of time investment, I could make that an “A.”  Not too shabby!

In that same post, I also talked about the various settings in and around “debt settings.”  With debt settings, you can change units of debt (time, money), thresholds, and assumptions of working capacity.  For folks at the intersection of tech and business, this provides an invaluable way to communicate with the business.

But I really just scratched the surface with that mention.  You’re probably wondering what this looks like in more detail.  How does this interact with the NDepend features you already know and love?  Well, today, I’d like to take a look at just that.

To start, let’s look at the queries and rules explorer in some detail.

Introducing Quality Gates

Take a look at this screenshot, and you’ll notice some renamed entries, some new entries, and some familiar ones.

In the past, “Code Smells” and “Code Regressions” had the names “Code Quality” and “Code Quality Regression,” respectively.  With that resolved, the true newcomers sit on top: Quality Gates and Hot Spots.  Let’s talk about quality gates.

Read More

Jun
18

By

Learning with Hands on Projects

Category: Language Agnostic Tags: |

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 and download NDepend to try it out.

If you want a surefire way to make money, look for enormous disparity between demand and supply.  As software developers, we understand this implicitly.  When we open our inboxes in the morning, we see vacuous missives from recruiters.  “Hey, dudebro, we need a JavaScript ninja-rockstar like you!”

You don’t tend to see vaguely patronizing, unflinchingly desperate requests like that unless you sit on some kind of goldmine.  They approach us the way one might approach a mischevious toddler holding a winning lottery ticket.  And, of course, anyone would expect that with wildly disproportionate supply and demand.

But, for us, this transcends just writing the code and oozes into learning about it.  Like baseball teams playing the long game, companies would rather grow their own talent than shell out for high-priced free agents.  And so learning about software might just prove more of a growth industry than writing it.

Look at wildly successful industry player Pluralsight.  It has built a benevolent commercial empire on the simple promise of democratized learning about technical pursuits.  Then you have a host of fast followers, an army of boot camp providers, and endless how-to blogs.  Sometimes it seem as though a gigantic wave of pressure pushes us all toward writing a bit of code.

The Learning Tools in Your Tool Belt

Let’s say that you’re convinced.  You see the money to be made, or you simply feel drawn to the profession.  You want to get involved, but don’t quite know where to start.  What sorts of learning can developers avail themselves of?

While I won’t call this an exhaustive list, I can offer some general categories of learning.  First, consider theoretical, passive learning.  You crack open some book called, “Principles of Modern Web Development” and get to reading.  Second, you have classroom-style learning.  An instructor leads your lessons, curates information, and engages you in Q&A.  And, third, you have hands on learning.  With this kind of learning, you put actual concepts into practice.

Understand that I do not consider these mutually exclusive by any means.  Any serious leaning plan worth its salt is going to incorporate elements of all of these (and probably other form categories that escape me at the moment).  But understanding the flavors will inform the rest of this post.

Read More

Jun
14

By

The One Thing Every Company Can Do to Reduce Technical Debt

Category: Language Agnostic Tags: , | 7 Comments

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 technical debt functionality in the latest version of NDepend.

The idea of technical debt has become ubiquitous in our industry.  It started as a metaphor to help business stakeholders understand the compounding cost of shortcuts in the code.  Then, from there, it grew to define perhaps the foundational of tradeoffs in the tech world.

You’d find yourself hard pressed, these days, to find a software shop that has never heard of tech debt.  It seems that just about everyone can talk in the abstract about dragons looming in their code, portending an eventual reckoning.  “We need to do something about our tech debt,” has become the rallying cry for “we’re running before we walk.”

As with its fiscal counterpart, when all other factors equal, having less tech debt is better than having more.  Technical debt creates drag on the pace of new feature deliver until someone ‘repays’ it.  And so shops constantly grapple with the question, “how can we reduce our tech debt?”

I could easily write a post where I listed the 3 or 5 or 13 or whatever ways to reduce tech debt.  First, I’d tell you to reduce problematic coupling.  Then, I’d tell you to stop it with the global variables.  You get the idea.

But today, I want to do something a bit different.  I want to talk about the one thing that every company can do to reduce tech debt.  I consider it to be sort of a step zero.

Read More

Jun
7

By

Adding Static Analysis to Your Team’s DNA

Category: .NET Tags: , |

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 play with adding it to your team’s build.

Stop me if this sounds familiar.  (Well, not literally.  I realize that asynchronous publication makes it hard for you to actually stop me as I type.  Indulge me the figure of speech.)  You work on a codebase for a long time, all the while having the foreboding sense of growing messiness.  One day, perhaps when you have a bit of extra time, you download a static analyzer to tell you “how bad.”

Then you have an experience like a holiday-time binge eater getting on a scale on January 1st.  As the tool crunches its results, you wince in anticipation.  Next, you get the results, get depressed, and then get busy correcting them.  Unlike shedding those holiday pounds, you can often fix the most egregious errors in your codebase in a matter of days.  So you make those fixes, pat yourself on the back, and forget all about the static analyzer, perhaps letting your trial expire or leaving it to sit on the shelf.

If you’re wondering how I got in your head, consider that I see this pattern in client shops frequently.  They regard static analysis as a one time cleanup effort, to be implemented as a small project every now and then.  Then, they resolve to carry the learning forward to avoid making similar mistakes.  But, in a vacuum, they rarely do.

A Better Course of Action: Incorporate the Tool

For the remainder of the post, I’ll refer to NDepend, both because of my familiarity with it and because it seems entirely appropriate for the NDepend blog.  But the principles here could apply to many static analyzers or other types of tools.

Simply put, you should not forget the tool.  On the contrary, you should expand your relationship with it.  You should add it to your build and to your process as a developer.

This approach requires very little effort.  At a bare minimum, you can modify your build to generate a report and run the tool prior to each commit.  Doing this tightly integrates code quality and trends into your development process.  They become constant fixtures, rather than periodic, one-off projects.

But that covers the “how” and not so much the “why.”  Let’s address that in the remainder of the post.  What benefits do you realize from using NDepend on a continuous basis?

Read More

May
30

By

Detecting Performance Bottlenecks with NDepend

Category: .NET Tags: , , | 2 Comments

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 NDepend and see what it can tell you about your code.

In the past, I’ve talked about the nature of static code analysis.  Specifically, static analysis involves analyzing programs’ source code without actually executing them.  Contrast this with runtime analysis, which offers observations of runtime behavior, via introspection or other means.

This creates an interesting dynamic regarding the idea of detecting performance issues with static analysis.  This is because performance is inherently a runtime concern.  Static analysis tends to do its best, most direct work with source code considerations.  It requires a more indirect route to predict runtime issues.

For example, consider something simple.

public void DoSomething(SomeService theService)
{
    theService.DoYourThing();
}

With a static analyzer, we can easily look at this method and say, “you’re dereferencing ‘theService’ without a null check.”  However, it gets a lot harder to talk definitively about runtime behavior.  Will this method ever generate an exception?  We can’t know that with only the information present.  Maybe the only call to this in the entire codebase happens right after instantiating a service.  Maybe no one ever calls it.

Today, I’d like to talk about using NDepend to sniff out possible performance issues.  But my use of possible carries significant weight because definitive gets difficult.  You can use NDepend to inform reasoning about your code’s performance, but you should do so with an eye to probabilities.

That said, how can you you use NDepend to identify possible performance woes in your code?  Let’s take a look at some ideas.

Read More

« Older Posts
Newer Posts »