Improve your .NET code quality with NDepend

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

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

The Case for the NDepend Dashboard Feature

If you hang around agile circles long enough, you’re quite likely to hear the terms “big, visible chart” and “information radiator.”  I think both of these loosely originate from the general management concept that, to demonstrably improve something, you must first measure and track it.  A “big, visible chart” is information that an individual or team displays in, well, big and visible fashion.  An information radiator is more or less the same concept (I’m sure it’s possible for someone who is an 8th degree agile black belt to sharp-shoot this, but I think you’d be hard pressed to argue that this isn’t the gist).

Big, Visible Information Radiators

As perhaps the most ubiquitous example imaginable, consider the factory sign that proudly displays, “____ days since the last accident,” where, hopefully, the blank contains a large number.  A sign like this is far from a feel-good vanity metrics; it actually alters behavior.  Imagine a factory where lots of accidents happen.  Line managers can call meetings and harp on the importance of safety, but probably to limited effect.  After all, the prospect of a floor incident is abstract, particularly for someone to whom it hasn’t ever happened.

But if you start putting a number on it, the concept becomes less abstract.  “Currently we have an incident every day, but we want to try to make it happen only once per month, and we’re going to keep track.”  Now, each incident means that the entire factory fails each and every day, and it does so visibly.  Incidents go from “someone else’s problem that you hear about anecdotally from time to time” to “the thing that’s making us fail visibly.”  And then you’ll find that doing nothing but making the number very visible will actually serve to alter behavior — people will be more careful so as not to be responsible for tanking the team’s metrics.

Continue reading The Case for the NDepend Dashboard Feature

Visualizing Your (Real) Software Architecture

Diagrams of software architecture have a certain aesthetic appeal to them.  They usually consist of grayscale or muted pastel colors and nice, soft shapes with rounded edges.  The architects that make them assemble them into pleasing patterns and flowing structures such that they often resemble 7-layer cakes, pinwheels, or slalom courses.  With circles and ovals arranged neatly inside of rectangles connected by arrows, there is a certain, orderly beauty.  If you’re lucky, there will even be some fluffy clouds.

If you want to see an example, here’s one that has it all.  It’s even got a service bus.  Clearly, the battle for quality was over long before the first shots were ever fired.  After the initial conception of this thing, the mundane details of bringing the architecture to life would likely have been a simple matter of digital paint by numbers.  Implement an interface here, inherit from a framework class there, and Presto!  Instant operational beauty that functions as smoothly on servers as it does in the executive readout power point.

At least, that’s the plan.

Continue reading Visualizing Your (Real) Software Architecture

With Code Metrics, Trends are King

Here’s a scene that’s familiar to any software developer.  You sit down to work with the source code of a new team or project for the first time, pull the code from source control, build it, and then notice that there are literally thousands of compiler warnings.  You shudder a little and ask someone on the team about it, and he gives a shrug that is equal parts guilty and “whatcha gonna do?”  You shake your head and vow to get the warning situation under control.

If you’re not a software developer, what’s going on here isn’t terribly hard to understand.  The compiler is the thing that turns source code into a program, and the compiler warning is the compiler’s way of saying, “you’ve done something icky here, but not icky enough to be a show-stopping error.”  If the team’s code has thousands of compiler warnings, there’s a strong likelihood that all is not well with the code base.  But getting that figure down to zero warnings is going to be a serious effort.

As I’ve mentioned before on this blog, I consult on different kinds of software projects, many of which are legacy rescue efforts.  So sitting down to a new (to me) code base and seeing thousands of warnings is commonplace for me.  When I point the runaway warnings out to the team, the observation is generally met with apathetic resignation, and when I point it out to management, the observation is generally met with some degree of shock.  “Well, let’s get it fixed, and why is it like this?!”  (Usually, they’re not shocked by the idea that there are warts — they know that based on the software’s performance and defect counts — but by the idea that such a concrete, easily metric exists and is being ignored.)

Continue reading With Code Metrics, Trends are King

Be Careful with Software Metaphors

skyscraper- software metaphors

Over the years, there have been any number of popular software metaphors that help people radically misunderstand the realities of software development.  Probably the most famous and persistent one is the idea that making software is similar to building a skyscraper (or to building construction in general).

This led us, as an industry, to approach software by starting with a knowledge worker “architect” who would draw grand schematics to plot every last detail of the software construction.  This was done so that the manual laborers (junior developers) tasked with actual construction could just do repetitive tasks by rote, deferring to a foreman (team lead) should the need for serious thinking arise.  It was important to lay a good foundation with database and framework selection, because once you started there could be no turning back.  Ever.  Should even minor plan changes arise during the course of the project, that would mean a change request, delaying delivery by months.

Software is just like construction, provided you’re terrible at building software.

This metaphor is so prevalent that it transcended conscious thought and crept its way into our subconscious, as evidenced by the “architect” title.  Given the prevalence of agile (or at least iterative) software development, I think you’d be hard pressed to find people that still thought software construction was a great model for building software.  I don’t think you see a lot of thinly sliced buildings, starting with an operational kitchen only and building out from there.

But there are other, more subtle, parallels that pervade the industry and lead to misunderstandings between “the business,” managers, and software developers.

Component Assembly

One such misunderstanding that I see frequently is to equate software components with physical components.  Consider a small application that consists of a login screen, a profile screen, and a screen that allows users to browse and make purchases.  There’s a natural tendency for people not involved with the code — particularly non-technical people — to view these as three isolated components.

The mental model thus becomes one of assembly.  This small project is like setting up a bedroom with disassembled furniture.  There’s a bed, a dresser, and a night stand, so what you do you when you have a tight timeline and plenty of labor?  Naturally, you create a bed team, a dresser team, and a night stand team and task them with working in isolation.  Once the individual components are ready, they can be integrated by positioning them appropriately within the room.  Right?

It’s the perfect plan, but it seems like the assembly teams can’t figure it out.  They keep talking about things you don’t care about, like databases, session management, and something called “common,” whatever that means.  So you tell them to have more meetings and figure it out.  But then they come back and talk about how it isn’t a good idea for two different teams to implement “leg.”  You patiently explain that a bed leg is different than a night stand leg or a dresser leg, and tell them to each make their own, and that you don’t know or care what “DRY” means.

Building isolated, pluggable components is a good idea, it makes business sense, and it allows you to pipeline labor.  Good developers will figure out how to make that sound plan a reality.  Right?

Not so much.  As it turns out, software components and physical components have some key differences.  Replicating a physical component involves construction, fabrication, or 3-D printing, whereas replication of a piece of software involves flipping a bunch of bits on a disk.  Reusing a physical component means hacking it off of a nightstand and taping it to a bed.  Reusing a software component is not destructive this way.  The differences go on, but the point is the same.  Asking a software team to operate as if it were building physical components is a recipe for friction between your mental model and theirs.financial debt as a good software metaphor

Financial Debt

This is liable to raise some eyebrows, because the concept of “technical debt,” is, perhaps, one of the best tools when it comes to facilitating a conversation between developers and people making budget decisions.  Technical debt (more or less) refers to a situation in which developers take a shortcut to get something to market  in a hurry, knowing that they’ll later have to undo their current work and “do it right.”  In other words, they’re paying a premium for short term liquidity, the way someone who incurs financial debt does.  They’ll later have to ‘repay the interest’ by spending more total time getting to the right solution.

Unlike the software metaphor of building construction, which I would argue has been largely damaging to the industry, financial debt as a metaphor has proved quite valuable.  But it has limits, and carrying the metaphor too far can lead to misaligned expectations.

When you take a loan from the bank, there are clear terms to payoff.  Generally this means that you’re constantly paying a small percentage of what you owe as a premium for the outstanding balance of the loan, and that percentage either doesn’t change, or it changes predictably.  With software?  Not so much.

Even assuming that it were straightforward to quantify the “less effort now for more effort later” trade off, you wouldn’t get a constant rate or even a predictably changing rate.  Software is a lot more volatile than that, and the “return rate” will depend on a lot more than what you’ve “borrowed.”

To put it in a way that’s perhaps easier to sink your teeth into, consider the software construct of “global state.”  If you don’t know what this is, think of it as a super power that software developers use to rip holes in the space time continuum, at least as it pertains to the world of software.  Let’s say that your software is a city, and there’s a traffic jam preventing you from shipping.  “No problem,” your developer says, “I can take care of that if you don’t mind some technical debt.”  She then proceeds to rip a wormhole into the middle of a busy street, diverting all traffic into what looks like some kind of desert somewhere.  Traffic problem solved.  Ship it.

You’ve taken out one single loan in this universe to get traffic to a manageable level.  Granted, that particular road is ruined by the wormhole, so you’ll need to build another one at some point, and that’s the interest you’ve agreed to pay.  That’s what you’re planning on doing when you get around to it.  And that all seems fine until you start getting weird reports of camels blocking traffic miles away, and scorpions stinging people going to work on traffic lights.

It turns out that ripping holes in the very fabric of your application has weird, unpredictable consequences that require repayment of debts you never planned for (and perhaps don’t understand the source of).  The lesson is that a decision to let (or encourage) developers to take shortcuts and make hacks can put your code in a degenerative state that neither of you is really prepared for.  If you aren’t careful, pressure to get them to ship will be more like navigating a minefield than shopping around for a mortgage.

Be Careful with Software Metaphors

It’s legitimately hard to mentally model software, particularly if you’ve never been a developer.  We live in a very tactile world and we use vivid mental models as mnemonics to aid our understanding.  Software is very abstract, conceptual, and precise in nature, and this makes it inordinately difficult to model in the way to which we’re accustomed.  We’re bad at bridging these worlds, and it’s perfectly understandable that we’re bad it.

Frankly, the only way to have a good mental model of software is through practice, and the realization that any analogies we use are transitory and incomplete at best.  Holding too close to any particular software metaphor is liable to trip you up in your decision making, so be very wary in conceiving of software development as being like anything other than… software development.

dev manager in a meeting

Mistakes Dev Managers Make

Managing a team of software developers is a tall order. This is doubly true when the line management includes both org chart duties (career development, HR administrivia, etc) and responsibility for the team’s performance when it comes to shipping. In this case, you’re being asked to understand their day to day performance well enough to evaluate their performance and drive improvement, in spite of the fact that what they do is utterly opaque to you. It’s like being asked to simultaneously coach a team and referee the game for a sport whose rules you don’t know. As I said, a tall order.

I’ll grant that, if you’re a dev manager, you may have been technical at some point, perhaps even recently. Or maybe not, but you’ve been around it long enough to pick up a lot of concepts, at least in the abstract. But in neither case, if you were asked what, exactly, Alice coded up yesterday, would you be able to answer. Whether it’s due to total lack of experience, being “rusty” from not having programmed in a number of years, or simply being unable to keep up with what 8 other people are doing, their work is opaque to you.

As with coaching/refereeing the game that you don’t understand, you can pick up on their body language and gestures. If all members of the team appear disgusted with one of their mates, that one probably did something bad. You’re not totally without context clues and levers to pull, but it wouldn’t be hard at all for them to put one over on you, if they were so inclined. You’re navigating a pretty tough obstacle course.

And so it becomes pretty easy to make mistakes. It’s also pretty understandable, given the lay of the land. I’ll take you through a few of the more common ones that I tend to see, and offer some thoughts on what you can do instead. Continue reading Mistakes Dev Managers Make

Refactoring is a Development Technique, Not a Project

One of the more puzzling misconceptions that I hear pertains to the topic of refactoring. I consult on a lot of legacy rescue efforts, and refactoring, and people in and around those efforts tend to think of “refactor” as “massive cleanup effort.”  I suspect this is one of those conflations that happens subconsciously.  If you actually asked some of these folks whether “refactor” and “massive cleanup effort” were synonyms, they would say no, but they never conceive of the terms in any other way during their day to day activities.

Let’s be clear.  Here is the actual definition of refactoring, per wikipedia.


Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior.


Significantly, this definition mentions nothing about the scope of the effort.  Refactoring is changing the code without changing the application’s behavior.  This means the following would be examples of refactoring, provided they changed nothing about the way the system interacted with external forces.

  • Renaming variables in a single method.
  • Adding whitespace to a class for readability.
  • Eliminating dead code.
  • Deleting code that has been commented out.
  • Breaking a large method apart into a few smaller ones.

I deliberately picked the examples above because they should be semi-understandable, even by non technical folks, and because they’re all scalable down to the tiny.  Some of these activities could be done by a developer in under a minute.  These are simple, low-effort refactorings.

Let’s now consider another definition of refactoring that can be found at Martin Fowler’s website.

“Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant.”


I took the wikipedia definition and used it to suggest that refactorings could be small and low-effort.  Fowler takes it a step further and suggests that they should be small and low effort.  In fact, he suggests that they should be “too small to be worth doing.”  That’s fascinating. Continue reading Refactoring is a Development Technique, Not a Project

NDepend Case Study: Increasing Development Efficiency in the Medical Laboratory Sector

Developing applications for use in the health care industry is stressful because the margin of error is almost non-existent. Whether your tool is for treatment, research, or analysis, it needs to be dependable and accurate. The more complex the application is, the higher the chance for errors and delays in development. Dependable companies abide by rigorous methodologies to develop their code before deploying it to clients. In this NDepend case study, we learn why a company in this sector chose NDepend, and why it became an integral part of their development process.

Stago works in the medical lab industry, producing lab analysis tools that focus on haemostasis and coagulation. Working hard for over 60 years and valuing long term investments, they have created a name for themselves in the industry. A few years ago, they wanted to make their software development process more efficient. In addition, they wanted to easily enforce their own best practices and code quality standards across their teams. The goal was to be able to catch issues earlier in the development cycle to cut costs and time spent on quality assurance post-development.

“We selected NDepend after reviewing all the other options on the market and it quickly became the backbone of our development effort.”
– Fabien Prestavoine, Software Architect at Stago

We are very grateful for Stago for sharing their success story with us. Stories such as these is one of the main driving forces behind creating one of the most comprehensive and powerful .NET analysis tool on the market. Since implementing NDepend, Stago has:

  • Easily met all delivery deadlines
  • Cut both cost and time spent on quality assurance
  • Delivered a consistently dependable product
  • Improved communication between their developers and architects

To read more about how NDepend helped Stago streamline their development process, click here to download a PDF of the complete case study.

Or check out this slideshow:

Software Rewrite: The Chase

Last week, a post I wrote, “The Myth of the Software Rewrite“, became pretty popular.  This generated a lot of comments and discussion, so I decided just to write a follow-up post to address the discussion, as opposed to typing a blog post’s worth of thoughts, distributed over 20 or 30 comments.  This is that post.

No Misconceptions

First of all, I want to be clear about what I’m talking about.  I’m specifically talking  about a situation where the prime, determining factor in whether or not to rewrite the software is that the development group has made a mess and is clamoring to rewrite it.  In essence, they’re declaring bankruptcy — “we’re in over our heads and need outside assistance to wipe the slate clean so we can have a fresh start.”  They’re telling the business and their stakeholders that the only path to joy is letting them start over.

Here are some situations that the article was not meant to address:

  • The business decides it wants a rewrite (which makes me skeptical, but I’m not addressing business decisions).
  • Piecemeal rewrite, a chunk at a time (because this is, in fact, what I would advocate).
  • A rewrite because the original made design assumptions that have become completely obsolete (e.g. designed around disk space being extremely expensive).
  • Rewriting the software to significantly expand or alter the offering (e.g. “we need to move from web to mobile devices and offer some new features, so let’s start fresh.”)

A Lesson From Joseph Heller

Joseph Heller is the author of one of my all time favorite works of fiction, Catch 22.  Even if you’ve never read this book, you’re probably familiar with the term from conversational reference.  A catch 22 is a paradoxical, no-win situation.  Consider an example from the book.

John Yossarian, the ‘protagonist,’ is an anti-heroic bombardier in World War II.  Among other character foibles, one is an intense desire not to participate in the war by flying missions.  He’d prefer to stay on the ground, where it’s safe.  To advance this interest, he attempts to convince an army doctor that he’s insane and thus not able to fly missions.  The army doctor responds with the eponymous catch 22:  “anyone who wants to get out of combat duty isn’t really crazy.”

If you take this to its logical conclusion, the only way that Yossarian could be too crazy to fly missions is if he actually wanted to fly missions.  And if he wanted to fly them, he wouldn’t be noteworthy and he wouldn’t be trying to get out of flying them in the first place.

I mention this vis a vis software rewrites for a simple reason.  The only team I would trust with a rewrite is a team that didn’t view rewriting the software as necessary or even preferable.

It’s the people who know how to manufacture small wins and who can inch back incrementally from the brink that I trust to start a codebase clean and keep it clean. People who view a periodic bankruptcy as “just the way it goes” are the people who are going to lead you to bankruptcy. Continue reading Software Rewrite: The Chase