A Technical Debtor

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/czo

I just got notice that I’ve been renewed as an MVP for the 5th year!

Congrats to all the other MVPs that got renewal notices – or awarded for the first time – today.

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/bd0

I found out today that, if you go to Help >> Troubleshooting in VS2010 (SP1), you’ll get lots of cool performance recommendations. You can also see these at: http://msdn.microsoft.com/en-us/vstudio/ff716700

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/bbm

I’m not the first to post this, by any means. However, you can try Azure for 30 days, free of charge. Details are at http://bit.ly/CRAzurePass. You’ll need to use promotion code DPCE01 (that’s a “zero” not an “o”).

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/bbJ

WCF services under Azure have a nasty habit of not really telling you what you need to know. Having fought through this – and having been challenged to find exactly what I needed in a Google search, I thought I’d add some more specific info here.

Before I do, let me say thanks to Steve Marx, whose blog posts and forum answers pointed me in the right direction.

Here are the exceptions that surfaced:

ConfigurationErrorsException: Could not create Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener

SEHException was unhandled by user code: External component has thrown an exception.

(As a side note, I particularly like how descriptive the latter exception wasn’t. This is a great example of how not to throw useful exceptions.)

Both of these were caused by different code, with the same root cause. When I had created the service reference, I neglected to edit the configuration file to point to the Azure endpoint instead of an IIS endpoint.

That is to say, I didn’t have this endpoint in my web.config.

Well, hopefully, this will help you not have the same difficulties I had in tracking down the cause of this exception.

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/bbI

The Rocky Mountain Tech Trifecta is an annual event held in Denver in late February or early March. The last couple of these have been amazing events, with great speakers like Beth Massi, Scott Hanselman, David Yack, Kathleen Dollard, Ben Hoelting, Paul Nielsen… need I go on?

Registration is open at http://www.rmtechtrifecta.com. The speaker list hasn’t been finalized, but it’s sure to be another great event. Don’t miss it!

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/bJI

Okay, this is one I’ve been meaning to write for far too long. (So long, in fact, that NDepend 3 is released already, and has been for some time now.) One of the indispensable tools I use is NDepend. This is a great code analysis tool, providing not only valuable insight into our code base, but also visualization tools that let me easily convey a sense of architectural issues to management. Whenever I need to understand why something isn’t working the way I think it should, or I get the dreaded “cannot add this reference because of a circular dependency” message, my first stop is NDepend.

To give you some idea of the scale, I work daily with a solution that runs about 110 projects, and around 600KLoC. (There’s more than that in the solution, but most of the rest involves reporting.) One of the things I like about NDepend is that it has a “metrics view” that lets you easily see the relative size of the pieces of the application. What I can’t show easily is that, when you mouse over the boxes, you get more details about the contents of that box. In the image below, the red text gives details about a specific method with 3 lines of code. The two projects on the left are UI projects, and they account for a pretty large proportion of the code.

I use the “dependency” view quite often. It’s a little scary at first, since it can generate a diagram that looks like this:

However, once I remove all of the system libraries and third-party libraries, it gets more reasonable (rotated for space reasons):

I know, I know…. “more reasonable?!?!” We have several applications in that solution. It’s a simple enough matter to exclude all but the stack for one application. Things get much better then. (This is far more legible on my monitor, full-size…. a guy has to have some secrets!)

Even with the default arrangement of the projects, you can see that there are architectural layers in the application. (Yes, it looks like they’re less than clean, and there is some of that. However, some of the ugliness is caused by cross-cutting concerns and DTOs.) To help figure out what’s going on, NDepend has a cool feature called “CQL”. Essentially, this is a query language written against the analysis data. For example, there’s a canned query for “Top Methods to Refactor”. Clicking on that and dialing the number of results up to 100 (the default is 10), yields the following picture:

What’s really awesome about the CQL queries is that the results are highlighted on the Metrics view, as shown here. Each class is organized into a large rectangle with smaller rectangles showing the individual methods. So, the partial graph at left shows that the top 100 methods that are prime refactoring candidates belong to just 4 classes. A more cynical person than I might even suggest that these same classes might be the causes of a fair number of bugs, since the most complex code is going to be in these classes.

A feature I don’t use often gives the ability to compare versions of code, so you could actually see how this code changes over time – hopefully, it would get more maintainable.

Another interesting way to visualize your dependencies is, appropriately, the “Dependency Matrix.” Patrick Smacchia (C# MVP and creator of NDepend) has written great articles on his blog (here’s one on NDepend 3, and another on using the dependency graphs to identify patterns) on how to interpret these, so I won’t belabor that topic.

Essentially, this is a graph of all of the dependencies within your code, either at the project, class or method level. (Although, truth be told, I find the project level most useful, unless I’m trying to find the specific class or method that has caused the architectural intent to be violated.)

At the moment, all this goodness is a stand-alone app … but I’ll soon be upgrading to NDepend 3, which has tight integration with Visual Studio. I can hardly wait to see just how cool that is!

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/aoh

One of the things that I failed to mention in yesterday’s post is that this series is going to be descriptive, not prescriptive. The biggest reason for that is that my experience is rather narrow in some regards, and I have some advantages that other developers and architects don’t enjoy. For example, the VP of Software at CCI (who I don’t report to, but who makes the calls about letting me borrow the developers!) was one of the earliest developers on our product… in the days when it was migrated to Access 2.0.

I mentioned briefly an example of what I refer to as “guerilla” architecture – that is, something that can be accomplished by a single person without a great deal of impact on, or effort required by, the rest of the team. (This was the modification of the code generation templates to use inheritance to reduce the amount of duplicated code.)

However, not all problems are this small, or can be accomplished without some sort of tacit approval. So, I’m going to touch briefly on some of the things I did to build consensus for putting such a massive effort into improving the architecture.

One of the things that became apparent very early was that there was an architectural pattern around the data that was causing developers at least twice as much work as was needed. I knew this, the developers knew this, the team leads knew this… but management wasn’t aware of the details. The first thing I did was bring the team leads on board, talking to them about the issue and explaining a proposed solution. This was a long-term effort, with a few words about it here and there. Part of the issue was that it was such a daunting change, and with such wide-reaching tendrils, that it honestly took me about 10 months to have the a-ha moment on how to attack the problem. (I mentioned in another post that I was on salary… it’s a good thing, too… I don’t think many consultants get the opportunity to take 10 months to propose a solution.)

Even before I had the solution in mind, however, I had sent a survey to all our developers. Among other things, it asked what the number one thing was that made their jobs more difficult. It really wasn’t any surprise when the unanimously indicated the very architectural pattern I wanted to change – as I said, pretty much everyone knew it was a problem. However, this gave me a concrete result that I could point to when discussing with management. I also have the benefit of having a leadership team above me that understands, not only software, but what happens when you keep a code base alive for a decade or more. By explaining that the architecture we had made development difficult, and would make maintenance even harder, I was able (along with the survey results) to present a compelling argument for change.

Next post, I’ll talk about what decisions ought to be considered once you’ve got approval to make massive changes.

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/aer

Mere minutes after I posted on “architectural refactoring,” Keith Nicholas has commented about the unsuitability of the term. He said:

you'd be better off calling it "evolutionary design"
The dilution of the word refactoring is disturbing, there's a certain rigor to "factorization" which shouldn't destroy the product.
refactoring != a cool way to say "I'm gonna change stuff"

There’s a fair bit to be said on this, so I thought I’d add another post rather than try to reply in an undersized comment box.

I agree that the use of "refactoring" in this context makes me a little squeamish. Keith is absolutely right that there's a lack of rigor here -- partly because the scope of the changes ensures that enough changes that this isn't really a refactoring in the Fowleresque sense.

However, as Fowler defines it, "evolutionary design means that the design of the system grows as the system is implemented". In the case I'm describing, the design isn't growing. Rather, suboptimal design decisions are being rethought, reworked, rebuilt. In an evolutionary sense, I suppose you could argue this is "growth," since the new architecture is "fitter" than the old.

However, to my mind, the word "evolutionary" brings with it a connotation that the improvement is a small forward step, building on what is already there -- not a massive reworking of the underpinnings of the architecture.

The scope of this effort is what's a little unusual. Kyle Baley, for example, talks here about architectural changes and how you know when it’s time to start over. Now, Kyle is a fellow Canuck and an all-around decent fellow. I even agree that, from what he describes, they made the right choice. However, he describes an effort that was scoped at a maximum of 2 developer-weeks. I had on the order of twice as much time personally into proof-of-concept for the changes that were made; all told, we invested something like 120 developer-weeks into the changes.

I have trouble calling a step of this magnitude “evolutionary.” Perhaps architectural renovation would be a more apt term.

(And, as a minor aside, when I said earlier that “I’m not even leaving the functionality intact,” I should have been clearer. The original architecture made heavy, brilliant and infuriating use of refactoring. That trait, among others, were ripped out. After the renovation, the code base had been reduced by close to 40%, and virtually every line of code had been touched, or at least inspected. However, the business functionality remained essentially unchanged – essentially, since we were able to identify and remove a fair number of bugs during the process.)

Thanks for keeping me honest, Keith – and for the great point you made.

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/aed

I’m delighted to reveal that I’ve been accepted to speak at the International Association of Software Architects (IASA) IT Architecture Conference (ITARC) in New York City, September 22-24th. I’ll be speaking on effective architecture refactoring… or, in other words, telling people about the mistakes I made, in the hopes that they won’t have to repeat them.

For those in NYC, this is well worth attending. The keynotes will be delivered by some people you may have heard of: John Zachman, Scott Ambler, George Paras, Len Bass and Angela Yochem. Eric Evans has been relegated to only giving a talk this year, as is Paul Rayner. The inimitable Doc List will be moderating an Open Spaces session. All in all, the sort of conference that takes about a month to fully sink in. Hope to see you there!

• Share This Post:
• 
• 
• 
•   Short Url: http://wblo.gs/aea