Playing with NDepend

Few days ago I used NDepend tool to analyze the code of one of our bigger projects in Sogeti. Here are my thoughts on the tool.

NDepend is a static dependency analyzer tool. It scans your compiled code, the PDBs and the source code and produces a “map” of your code dependencies, metrics and structures. It has been around for several years now, and it has kept beeing better in every new edition.

The default view of NDepend is the so-called “Report” that highlights all the potential issues with your code. It gives you a trove of information to optimize your code, in a HTML format that’s easy to share. The report contains the summary of all the main features of the tool: rule violations, dependency cycles, complex code and so on.

NDepend Report

The next feature that I used is the dependency visualization. There are two “flavours” to it: the dependency graph and the dependency matrix.

The dependency graph is easy to grasp but it can only be meaningfully used with a handful of classes and namespaces. It quickly becomes a mess with more than a couple of dozen objects.

NDepend Dependency Graph

The dependency matrix is a much more powerful tool. It can be used to spot dependency cycles, infrastructure classes, “god” classes, cohesion and coupling and so on. However, it’s not as intuitive to analyze as the graph, it takes some time playing with it to grasp the information without consulting the help windows.

NDepend Dependency Matrix

NDepend has a full set of code complexity and maintainibility rules. It can quickly highlight the most important issues so that you can concentrate on fixing the most critical parts of your code.

NDepend Code Rules

But it’s just the surface of it. NDepend has a full-blown language called CQLinq, akin to SQL, that allows you to query your code. You can find classes that have high coupling, methods that are too complex, nested structures in the code and a myriad of other code patterns.

NDepend CQLinq

In my opinion, NDepend is an invaluable tool if you’re concerned about your code quality (and you should be). It takes some time to grasp and master all the power of it, as it can be an overwhelming experience for a first-time user, but it’s a time well invested.

Thanks to Patrick Smacchia (the main force behind NDepend) for the NDepend license for MVPs, that allowed me to fully evaluate the tool.


Where Are You Going, SharePoint?

I would like to do a short retrospective look to the rapidly-changing landscape of SharePoint in the last few years, followed by a personal opinion on the future of SharePoint. It is a fairly long rant piece, so it is advised to have at least 15 minutes at hand to read it throughly.

Note: It is obvious to me but won’t hurt to mention that everything mentioned here expresses my own opinion and my own opinion only. 

How SharePoint has evolved from 100% on-premise to hybrid and cloud

In the early years of SharePoint development, in the early 2000’s, the development on the SharePoint platform was restricted to the server-side code. You could only code what you could put inside the SharePoint box. Of course, the server object model let you do all sort of things, as it is the same model that was used internally by SharePoint (at least a significant portion of it). But, you were responsible for the performance and side-effects of that code as it was run inside the SharePoint very own IIS process or service. As long as you did your homework, the future was bright for you.

For the less prone to scare the IT people by stubbornly insisting on putting custom code in the SharePoint box, there was a second option: the ASMX web services. Clumsy as they were, they were the only option if you couldn’t (or wouldn’t) put your custom code in SharePoint servers.

Over the years, that approach was good and great. Best practices and guidance began to evolve and we saw less and less SharePoint "crime scenes" (as Matthias Einig puts it).

And then, Microsoft began hosting its own product, by launching SharePoint Online inside its BPOS (Business Productivity Suite).

Suddenly, Microsoft began feeling how it was to actually host SharePoint. They began to experience the same nightmares IT admins over the world had to experience when they wanted to patch their SharePoint servers. They weren’t shielded any more from the customers running SharePoint: they were the customer running it and they were responsible for their tenants and their SharePoint data.



SharePoint Online administrator Installing cumulative updates

During the first teething years of SharePoint Online, one thing emerged clear and painfully clear. It was the insight that what worked for a single datacenter doesn’t work for cloud environment, with multiple tenants. The customizations wouldn’t scale and what’s even worse, they would break with the frequent updates to the SharePoint version on Microsoft servers. Even with the stop-gap measure of sandboxed code, the customizations that involve code didn’t behave as Microsoft wanted for their hosting environment.

In other words, during the golden years SharePoint allowed massive customization with server-side code. You could build web parts, web controls, timer jobs, application pages and all sort of server-side extensions. You were allowed to shoot yourself in the foot and bring your SharePoint to a halt, because it was your own datacenter. You (or hopefully your governance committee) would decide what was more important. Also, you could put arbitrary code in your customizations and be happy with it. However, when you depend on your SharePoint servers running smoothly and flawlessly, it is only possible with plain-vanilla SharePoint structures with no customization. As careful as you were, there was always a penalty for your custom code. As for the security of that code, things such as CAS policies were a step in a right direction but many customers just turned their code trust level in web.config to Full and live with it.

How scalability and performance have taken precedence over customization

But, not Microsoft. Microsoft could not allow SharePoint Online to fail. Also, the prospect of selling monthly licenses instead of a one-time license was meant to inject significant cash flow into Microsoft Office Division balance sheets. Between the need of the "less desirable" one-time customers (who wanted custom code) and the need of Microsoft SharePoint Online cash cow (who wanted scalability and performance), the scales tipped to the side of the scalability (pun not intended).

So, things such as client object model and finally  "cloud application model" came to be. Your code was allowed, as long as it run outside SharePoint. The infrastructure was put into place to allow your code to call into SharePoint without the need for explicit credentials. Your calls to SharePoint were carefully securized, throttled and channeled to allow for non-customized SharePoint parts to run without being blocked or delayed.

SharePoint erred on the side of the performance, banishing server code on cloud deployments and slowly banishing (or deemphasizing) even the declarative customization. As long as you are fine with the evolving standard SharePoint Online features, you are good to go. Want more? Plug in an app, even if the client object model didn’t allow for all the richness of the functionality that server object model did. Your application would run on your servers, consuming your resources and leaving their SharePoint instances out of your bad influence.

What’s the future for on-premise SharePoint customers?

But, what Microsoft doesn’t seem to get (or does seem to ignore) is the reality of the corporate customers. SharePoint was never a software for small companies. Yes, you could run a SharePoint Foundation (or Windows SharePoint Services before that) and it was free, but the need for the corporate-scale collaboration and knowledge management that SharePoint ushers is something that goes with the medium and big companies, as it breaks department silos and culture barriers. Also, the hefty price tag for the SharePoint license didn’t help.

Now, SharePoint Online as part of the Office 365 package is affordable. Even smaller companies could take advantage of it. But, are they doing it? In my experience, the vast majority of the Office 365 customers in small companies are more interested in Exchange Online, because running a mail infrastructure is something every company does, small and big, while running SharePoint is something that is not everyone’s piece of cake. Whenever I listen to Microsoft marketing machine trumpeting about "millions of Office 365 users" I can’t help asking myself how many of them are only using Exchange Online out of the whole Office 365 package. (Answer: I don’t know but I imagine that a vast majority).

So, here we have Microsoft cranking out new features to suit their "imaginary" customers that want wizards, flashy UI and shiny settings, while the real SharePoint customers with deep pockets are placed between a rock (declining investment in new on-premise features) and a hard place (the fact that Office 365 deployments customization options are limited at best). They need freedom to customize their SharePoint to suit their needs, and right now the capabilities of the app model and Office 365 app model are just not enough. Not to mention the need for UI customization, which is the first thing that corporate customers want. They now have to jump through hoops just to deploy and keep their master pages, CSS and JS files from breaking with each SharePoint Online update. Not good.

As a side note, the need of the on-premise clients for top-of-the-notch social without hassle was the driver that made Beezy, the company I work for, possible. If that capabilities were available on SharePoint Server, we would be out of business even before starting.

That has been by experience with the SharePoint customers that are more or less "invited" to become Office 365 customers. Only a few of them venture into the hybrid world of connecting their on-premise farm with the Office 365 farm. In the future, this number will increase, but will it ever be so overwhelming as to dispense with the on-premise SharePoint. My opinion is that it won’t. We won’t see the end of on-prem SharePoint in the foreseeable future.


What lies ahead?

Why I so firmly believe this? First, the cloud is not fully parring the on-prem world. I know that SharePoint is just the "expression" of the solution for a business need, but right now going to the cloud makes you lose certain flexibility (in the depth of your customization) and gain another flexibility (on the deployment and operation costs). So, there is still a gap between what cloud enables you to do and what SharePoint Server enables you to do. In the future I believe that the gap will be closing, but not disappearing. Yet, the cloud will allow us to plug-and-play different services and technologies to build our solutions. It will widen our choice of options, not narrow it down.

I think that we will see more and more hybrid deployments but there will always be on-premise deployments with workloads that are only suitable for that scenario. Conversely, there will be (and there are) cloud-only scenarios such as machine-learning powered Delve and Outlook Clutter that can’t be deployed on-premises as it requires some really BIG data (pun intended) to work properly. But, for a big company with their own processes and dynamics, I just can’t see a cloud-only environment, no matter how hard I try to imagine.

However, the love SharePoint Server got from Microsoft during the last decade has gone to the new, cloudy sweet-heart: SharePoint Online. It is a fact.

I would like to imagine the future SharePoint Server (call it vNext or 2015 or whatever) to be more like Windows 8 than Windows XP. Windows XP had to be replaced with Windows Vista and it was a fairly traumatic deployment. But, Windows 8 was "updated" to Windows 8.1 with little or no hassle, and you ended up with very different Windows. In another times, it maybe would be called Windows 9 and would have to be deployed in a "traumatic" fashion. In the same light, I can imagine future SharePoint getting periodic updates (as Windows or Visual Studio do), with new and enhanced features, not only bug fixes. I can imagine that the main development branch is the cloud one, and that not all the features can translate to the on-premise version, but I can’t imagine a reason for not having that kind of quick, iterative development for the cloud that "trickles down" to the SharePoint Server periodically. Gone are the days of 3-year cycle for SharePoint Server, the cycle is now merely couple of weeks long. It is perfect for the cloud, but I think (and hope) that it will also add enhancements to the on-premise customers. Let’s face it, SharePoint is a fairly mature product with a broad set of features. What corporate customer need is not to have the latest eye-candy, "sexy" features but fixing the long-standing pains of basic, staple SharePoint features. I’m not saying that there is no value in the new features, there certainly is. However, there is no excuse for having half-baked functionality any more in SharePoint, online or not.

What’s the future for SharePoint specialists?

In the end, where it leaves us, the SharePoint developers, architects, consultants, Power Users, customizers and so on?

It is normal to feel a certain amount of dizziness and feeling of being let down. Microsoft messaging to the customers is something chronically ambiguous, although the transparency set by some of the teams in Microsoft is exemplary in the last years. They are improving. But still, giving mixed signals or flatly ignoring the rightful questions of the corporate users is making them question whether Microsoft commitment can be taken seriously. (Yes, I mean Silverlight and sandbox solutions and autohosted apps and so on).

Well, let’s face it: the world is changing. It never stopped changing. We can’t cling in the comfort zone anymore, if we ever did. I think that the pace of technological change has accelerated and with it comes a natural reluctance to change (I explain some of it in my Pluralsight course about human behavior). We have to embrace that change.

What does it mean? It doesn’t mean drinking the Microsoft Kool-Aid and firmly believing their marketing messages. They have all the right to send whatever signals they want, but we SharePoint specialists are paid to assess and advise our clients about their technology, not to repeat it like trained parrots. In many cases the message is perfectly valid, but in many cases it is not and we should know better. As I said before, SharePoint (and Office 365) were, are and will be the tools to build solutions for business needs. Not the solutions themselves. Sometimes, we lose track of this simple fact.

It means that we should learn, practice and keep raising the bar. We are on the front line of technology and we should be prepared. Luckily, it has never been more easier to learn new things and find guidance (The OfficeDev PnP team is just the example of that). Dedicate some time to play with the cloud, to experiment with apps, JavaScript and hybrid environments, to fiddle with Delve and Office Graph and to keep pushing the envelope. You will be acquiring new tools to build your technological solutions to business problems. That’s your job as a technology specialist.

What are your opinions? I’m eager to know them.

All images provided by

Business Value of Social Computing (III)

Welcome to the third installment of the business value of social computing post series. You can review the first and the second post of the series, if you haven’t already done so. In this post I will higlight two main problems with the social computing today.

We have seen what social means and what parts make up the mosaic of social computing. We have also seen why do businesses use social and what benefits it can bring. However, businesses still cope with lack of adoption. Why is that? From our experience in deploying Beezy social network for SharePoint to our many customersmany customers, we have learned some key insights on the social success patterns, in the companies that have succeeded in social. We have also learned what doesn’t work, so to avoid it in future deployments.

Here are the two pain points with social computing today:

Social Is Slow to Grow

The enterprise social networks (ESN) are still a young technology. Even if they have been available for years now, they haven’t become mainstream until few years ago. If you compare it to a well-established technology such as OLAP datawarehouses or business process management (BPM), it still has to crystallize into best practice patterns and actionable guidance.

There are several reasons for this slowness in the adoption of social. It is a very disruptive technology, because it changes the way people work and share information. A change of this magnitude needs a lot of time to "stick" (some studies say that it can take 18 months for a change to become durable). In today’s fast-paced world, the instantaneous results we expect of deploying any new technology won’t be there with social. Embracing social in the company is a marathon, not a sprint. It has to be nurtured, encouraged and guided.

Also, the lack of clear guidance and the variety of use cases of social in different sectors and companies don’t help much to speed up the adoption. There are too many contradictory messages and guidelines out there. A company that wants to adopt social computing can’t just expect to plug it in and reap the benefits. It’s a slow-paced progress, but it’s also a steady journey. Have patience!

There Are Common Pitfalls in the Way

The second frequent pain point with ESN has to do with the common pitfalls and barriers to the successful adoption of social at work. Over and over again, companies have faced lack of social adoption and the root causes are very common between all of them.

The first cause of social failure is the lack of an overall strategy for social. As I said before, social computing isn’t a database engine that is simply plugged in. It needs to be deployed in the context of a greater business strategy, in order to achieve business goals. If you deploy first and ask for the business need later, you are putting the cart before the horse. Keep in mind that social is a tool, and not an end in itself. (You can check part 2 of the series for a refresher on the common business cases for social).

The second common cause of lack of adoption is having too many competing priorities. It means that the company is picking many desirable technology projects but doesn’t really commit hard on any one of them. While not putting all your eggs in the same basket is a common sense, not committing is akin to a paper tiger: looks strong from the distance but shaky when confronted. You will need "teeth" (business support and gravitas) to overcome resistance to change, and starting without that support is a recipe for a disaster. If you don’t have executive sponsors for your social endeavour, don’t even start. I have warned you Smile

The third cause is not having a clear business case. As I said few paragraphs before: every business has a unique case for social. You will have to find yours. If it’s lackluster or too broad, your users won’t find any value in the extra hassle that is needed to learn the new technology. It won’t work for them. Make sure to find your value proposition for social in order to start on the right track.


We have seen how social is by its nature slow to grow and how it’s easily derailed by common pitfalls. If you plan your social computing deployment having into account these facts, your chances of success will be higher.


Do you have something to add to this conversation? Make sure to leave a comment below.

How Did The Prediction End on SP2010?

More than a year ago, I wrote a summary post about the rumours and buzz around the next version of SharePoint (SP2010). My post has seen a lot of translations and links to it from different blogs. Now I’d like to revisit it and check what has been correctly predicted and what has not.

Let’s see how do I stand as a crystal-ball reader.

Feature Outcome
The SharePoint v14 / 2009 will be shipped only as x64 installation Included in SP2010

Silverlight 2.0 webparts or UI will be present.

Included in SP2010
SQL tables-like behaviour for SharePoint lists Included in SP2010 as External Content Types
If the user has Groove client installed, more options will be displayed for data synchronization, in more seamless way. Included in SP2010 as SharePoint Workspace
Master data source for keeping only one version of the truth. Included in SP2010 as centralized metadata management
SharePoint UI will produce clean XHTML-compliant output. Not included in SP2010. The output is WCAG-compliant (no tables) but not strict XHTML.
FAST-based enterprise search as a Search replacement. Webparts that show FAST search results. Included in Enterprise license of SP2010
Custom filters won’t be necessary to index and extract metadata from ODF and PDF files. Not included in SP2010. Third-party IFilters are still necessary
Content Management Interoperability Services will allow SharePoint to communicate with other ECMs via web services. Included in SP2010
Claims-based Authentication mechanism Included in SP2010

8 out of 10 predictions turned true. Maybe I’ve been in the wrong industry all this time 🙂

Review: Five Ways SharePoint Can Save You Money

Microsoft released few months ago a business-oriented guide that explains how businesses can actually save money in these times of crisis using SharePoint.

The essence of the whitepaper is that you can either reduce the total cost of ownership (TCO) or increase the return on investment (ROI). SharePoint can help the company to achieve both objectives.

The actions that reduce TCO are:

  • Reduce IT costs and complexity
    • Use a single platform for your enterprise applications
    • Single license and support
  • Reduce development costs
    • Use out-of-the-box features to save time
    • Leverage your existing ASP.NET knowledge
  • Simplify management and training
    • Single interface for IT Administrators and Power Users

The actions that increase ROI are:

  • Improve employee productivity
    • Collaboration tools, Web 2.0, workflows, business forms
  • Enhance the effectiveness of sales and customer service
    • Aggregate the business information across the enterprise


Download the guide from Microsoft Download Center

Gartner Magic Quadrant for ECM 2008


Microsoft Office SharePoint Server 2007 has moved from the “Visionary” quadrant into “Leaders” quadrant, in the past year. According to Gartner’s Magic Quadrant for Enterprise Content Management (ECM) for 2008, this move has been fuelled by steady course of SharePoint and the number of the companies that have implemented it. Gartner recognizes that SharePoint OOB offers basic tools for six core ECM features, supported by a strategic vendor that is Microsoft.

Gartner also warns that SharePoint is still lacking improvements in scalability and replication management, as well as quality imaging and BPM tools.