NDepend

Improve your .NET code quality with NDepend

old computer, future legacy code

Legacy Code for Developers: Managing your Manager

Here’s a campfire horror story of legacy code that probably sounds at least somewhat familiar.

One day, your manager strolls by casually, sipping a cup of coffee, and drops a grenade in your lap.  “Do you think we can add an extra field to the customer information form?”  Sure, it may sound innocuous to an outsider, but you know better.

The customer information form is supported by something written almost a decade ago, by a developer long departed.  Getting that data out of the database and onto the form prominently features a 60,000 line class called DataRepositoryManagerHelper and it also makes use of a gigantic XML file with odd spacing and no schema.  Trying to add a field to that form casts you as Odysseus, navigating between Scylla and Charybdis.  In fact, you’re pretty sure that author of the legacy code made it necessary for the assigned developer to cut off and sacrifice a finger to get it working.

Aware of all of this, you look at your manager with a mix of incredulity and horror, telling her that you’ll need at least 6 weeks to do this.  Already swirling around your mind is the dilemma between refactoring strategically where you can and running exhaustive manual testing for every character of the source code and XML that you change.  It’s now her turn to look incredulous and she says, “I’m just asking for a new field on one form.”  You’ve told her before about this, and she’s clearly forgotten.  You’re frustrated, but can you really blame her?  After all, it does sound a little crazy.

Continue reading Legacy Code for Developers: Managing your Manager

Static Analysis for Small Business

I was asked recently, kind of off the cuff, whether I thought that static analysis made sense for small business.  I must admit that the first response that popped into my head was a snarky one: “no, you can only reason about your code once you hit 1,000 employees.”  But I understood that the meat of the question wasn’t whether analysis should be performed but whether it was worth an investment, in terms of process and effort, but particularly in terms of tooling cost.

And, since that is a perfectly reasonable question, I bit my tongue against the snark.  I gave a short answer – more or less of “yes,” but it got me thinking in longer form.  And today’s post is the result of that thinking.

I’d like to take you through some differences between small and large organizations.  And in looking at those differences, I will make the perhaps counter-intuitive case that small companies/groups actually stand to benefit more from an investment in static analysis tools and incorporation of the same into their software development processes.

Continue reading Static Analysis for Small Business

A Visual Studio script that saves time and pain

After years of pain, I finally found a clean-and-definitive way to get rid of the dreadful issue Could not copy assembly, the process cannot access the file because it is used by another process!

Locked assembly

I have no idea how many .NET developers are coping with this issue, but on our side it used to be daily and there are many situations where an assembly file gets locked:

  • sometimes VS just load in-process the assembly, or the PDB file or the .xml documentation file, for an unknown reason (usually after a debug session)
  • sometimes the culprit seems to be vshost.exe
  • sometimes the culprit is the test runner process
  • sometimes, after a smoke test session, one just forgets to close all processes that hold assemblies…
  • …or sometimes it is just a zombie process that should have stopped but just didn’t!
  • and when developing a VS extension, all of those situations are happening more often

When the culprit process was not obviously identified, I started Process Explorer to kill it! And when the culprit process is my current VS instance, it means I need to restart it and interrupt current work for significant time and then lose my mental focus!!


The clean-and-definitive solution to this problem, is this script to copy in a .bat file. This script must be invoked from the VS project pre-build-events. It just moves the assembly file, the .pdb file and the .xml documentation file to a dumb location (if the .pdb or .xml file is missing no problem).

The key is that when a process locks a file, Windows authorizes to move and rename the file. I found the original idea from this stackoverflow answer, that itself found it from a Keyvan Nayyeri blog post that seems to have been removed.

To invoke this script just add this in all your VS project pre-build events command line. If you wish the script name and location to be different, just adapt $(SolutionDir)\BuildProcess\PreBuildEvents.bat.

PreBuildEvent

Notice that this script does the job no matter the actual configuration (Debug or Release) and no matter if the compilation is started from VS or from any other script.

-Patrick

A Manager’s Guide to Legacy Code

If you have a sadistic streak and manage a team of software developers, it’s probably high entertainment to dredge up some old, dusty piece of software and then to task them with maintaining it. If, on the other hand, you’re a normal human being and you’re asking this because it’s necessary for your business, you brace yourself.  After all, this is legacy software, and the reaction of the team is likely to be quite predictable.

 

Alright, let’s take a look at this thing.  Oh, man, look at that right there.  A global variable.  And — oh my god — there are dozens of these things.  Who even wrote this?  And, look at this over here.  That’s the kind of idiotic, backward code that we used to have to write 20 years and 6 language versions ago when this code was current.  But even when it was current, this code was horrible.  This was obviously written by a trained ape.

 

When you’re a developer, the only thing worse and more contemptible than the uninformed code you wrote years ago, is the code that someone else wrote years ago.  Not only is it alien to you in makeup and reasoning, this legacy code also features patterns that have gone out of date or even been forgotten.

But lest you, as a manager, assume that this is simply a matter of developers being prima donnas, consider that an encounter with legacy code bothers developers precisely because it renders them less effective. They’re professionals, wanting to do good work, and the lead balloon you’ve dropped in their lap is an impediment to that.

Continue reading A Manager’s Guide to Legacy Code

NDepend vs. ReSharper

Not too long ago, someone asked me for a comparison of ReSharper (commonly and affectionately abbreviated R#) and NDepend.  I didn’t really grok the question, so I asked, “in what sense?”  The response was, “well, let’s say NDepend vs ReSharper — which makes more sense for a given person?”  Bemused, my slightly snarky quip in response was, “doctor vs dentist — which makes more sense for a given person?”

I went on to clarify the analogy.  Doctors and dentists both provide healthcare services, so, in this sense, one could theoretically view them as competitors.  But practically speaking, that competition is going to be rare or nonexistent.  There is an intersection between what the tools offer, as would be the case if a dentist noticed a throat infection or a doctor needed to peer into your mouth.  And yet that intersection is small because the two products, like doctors and dentists, have fundamentally different charters.

I’ll return to that in a bit, though.

Continue reading NDepend vs. ReSharper

The Better Code Book – Our MVPs of 2015

We firmly believe spaghetti belongs on the dinner table and not in code. Our mission when starting NDepend was to create a tool to make best coding practices easier to maintain and improve. Writing has always been part of our message (see Patrick Smacchia’s work on CodeBetter.com) and we are proud to present our favorite pieces of writing from around the web in the last year, collected in what we are calling the Better Code Book.

We wanted to focus not only on how people use NDepend to improve their code for developers and architects, but also how to use static analysis in a broader, management sense. We are extremely grateful for our contributors in this project. Let us introduce them:

Bjørn Einar Bjartnes is a developer at the Norwegian Broadcasting Corporation. His current role is a backend developer at the API team, serving web, mobile, TV clients and more metadata about programs- and video-streams. He holds a MSc in Engineering Cybernetics and has a background from the petroleum industry, which has probably shaped his view on systems design. Also, Bjørn is active in the local F# Meetup and a proud member of the lambda club, playing with all things useless related to computers. You can also follow him on Twitter: @bjartnes

Jack Robinson is a twenty-something student in his final year of a degree in Software Engineering at Victoria University of Wellington. Currently an Intern Developer at Xero, he enjoys writing clean code, playing a board game or two with his friends, or just sitting down and watching a good film. You can read not just his musings on computer science, but also reviews on films and more at his website jackrobinson.co.nz

Prasad Narravula is a programmer, architect, consultant, and problem-solving leader.  He helps teams in agile development essentials- feedback loops to fail fast, enabling (engineering) practices, iterative and incremental design, starting at the right place, discovery, and learning. When time permits, he writes at ObjectCraftworks.com.

Erik Dietrich, founder of DaedTech LLC, is a programmer, architect, development coach, writer, Pluralsight author, and technologist. You can read his writing and find out more about him at http://www.daedtech.com/ and you can follow him on Twitter @daedtech.

Anthony Sciamanna is a software developer from Philadelphia, PA who has worked in the industry for nearly 20 years. He specializes in leading and coaching development teams, improving development practices for cross-functional teams, Test-Driven Development (TDD), unit testing, pair programming, and other Agile / eXtreme Programming (XP) practices. He can be contacted via his website: anthonysciamanna.com

Tomasz Jaskula is a software craftsman, founder and organizer of Paris user groups for F# and Domain Driven Design. He focuses on creating software delivering true business value which aligns with the business’s strategic initiatives and bears solutions with clearly identifiable competitive advantage. He is currently working for a big French bank building reactive applications in F# and C#. In his free time, he runs a startup project on applying machine learning with F# to the recruitment field, speaks at conferences and user groups, and writes blogs and articles for a French magazine for coders called “Programmez !” You can visit his site jaskula.fr

Continue reading The Better Code Book – Our MVPs of 2015

siemens logo

How Siemens Healthcare manages over 500 million lines of code – An NDepend Case Study

Siemens Healthcare produces imaging equipment for the medical sector in a variety of fields and is based in Germany. Looking to reduce development costs on the next generation of medical imaging equipment, Siemens decided on a platform approach. They have been kind enough to share what they did in an NDepend Case Study.

This brought forth three specific challenges for the company:

  • How can we guarantee the stability of APIs?
  • Can we even make a breaking change?
  • How do we guarantee quality over builds?

Continue reading How Siemens Healthcare manages over 500 million lines of code – An NDepend Case Study

Let’s Build a Metric Reconsidered

If you’ve been keeping track, you’ll noticed that it’s been a while since the last post in this series.  In case you’d forgotten or lost track, the primary goal is to build a composite metric experimentally.  I’ve been looking to work experimentally toward a “time to comprehend” metric.  The series also has a secondary goal, which is to take a tour of NDepend and see how it and static analysis in general work.

To lay my cards on the table, the reason I haven’t picked the series back up is a data-based one.  Simply put, not a lot of people read them, and the readership has waned since the beginning of the series.  On the bright side, the experiment has attracted a small, loyal following of people that participate in the code experiments, but that seems to be about it for the audience.  I’ve mulled over the reasoning for these posts not doing as well as the other posts I make to the blog, but, at the end of the day, the data is the data, and my main interest is providing the readership with material that interests you.

Because of this, I’m going to draw the series to a close before I had originally intended to do so.  Don’t worry — I’m not just going to abruptly call it a day.  Rather, I’m going to take the progress that we have made and turn it into a rough stab at a tentative, composite metric.  From there, I’ll call for one last experiment to see how that metric does.

Continue reading Let’s Build a Metric Reconsidered

cummincation breakdown between developers and architects

Bridging the Communication Gap Between Developers and Architects

If you want to set off a ceaseless, spirited discussion, ask a roomful of people what makes some music good and other music bad.  The opinions are likely to be as spirited as they are diverse, with, perhaps, good points to be had.  But consensus is unlikely.

If you want to see a similar dynamic in the software development world, ask a roomful of software developers what a software architect is.  What makes a person an architect?  Does the architect write code?  What kinds of decisions should an architect make?  What is the relationship between architects and developers?  Do developers report to the architect, or is it a “dotted line” reporting relationship?  Maybe they’re peers?  Do architects need to have a lot of domain knowledge?  Do architects need to be the best programmers (or at least have been at some point)?  You get the idea.

Go out and observe enough software shops in action, and you will see every different imaginable answer to these questions in every possible combination.  This fact alone lays seeds for myriad communication complexities between developers and architects.  In any shop, a developer is more or less a developer.  But the architect role varies widely and, as developers move from company to company, this creates confusion. Continue reading Bridging the Communication Gap Between Developers and Architects

NDepend in visual studio

Put a Little NDepend in your Visual Studio

The software development world is filled with what I think of as “Coke-Pepsi” debates. This is how my brain categorizes debates over preference that are almost entirely subjective. There is no right or wrong answer to “is Coke or Pepsi better?” The answer is, “whichever one you like better.”

Examples abound in the software world. Should you use a heavyweight IDE or a lightweight text editor? Which OOP language is ‘the best?’ And, speaking of OOP, should you use an OOP language at all, or should you use a functional one? Pascal casing or camel? The list goes on, but these sorts of things generally boil down to the comfort and preferences of the person or team.

It would be tempting to paint NDepend Standalone versus NDepend’s Visual Studio plugin with this brush. And, while I think you could make a pretty legitimate case that this too, is simply a matter of preference, I’d like to do a thought exercise today in which I lobby in favor of the integration approach. In my opinion, there are enough advantages that I might be able to sneak this one out of the Coke-vs-Pepsi realm. Continue reading Put a Little NDepend in your Visual Studio