<CharlieDigital/> Programming, Politics, and uhh…pineapples


More Thoughts on Object Oriented Code

Posted by Charles Chen

I've talked about writing object-oriented and domain-driven design before.

In talking with another dev this week, I think I have my simplest summary of object-oriented code yet: when  you are writing well written object oriented code, you'll know it by the questions being asked by your code.

So what does this mean?

A good example is the following:

FormData formData = GetFormData();

// Object-oriented? Not really:
bool isValid = FormDataUtil.IsValid(formData);

// Object-oriented:
bool isValid = formData.IsValid();

It's very subtle, but it's very easy to observe because you simply need to ask yourself if you are asking the questions to the right objects.  We don't ask FormDataUtil if the formData is valid, we ask the formData directly.

Primarily, what this will reflect is the principle of encapsulation.

When you are asking the right questions to the right objects, you'll find that the code is easier to read, easier to maintain, less fragile, and more natural to reuse.

If the code is well written, as first time users, we don't have to know that there is a class explicitly designed to validate the form data; we can find it easily on the class itself.

I don't think it gets any simpler than that and yet it is, to me, the very essence of what it means to write object-oriented code.


SharePoint’s Image Problem

Posted by Charles Chen

SharePoint has an image problem with many folks.

I've discussed it before, but I think I have a new perspective on the issue.

You see, I recently interviewed a candidate that was Microsoft Certified IT Professional: SharePoint Administrator 2010 and Microsoft Certified Professional Developer: SharePoint Developer 2010.  His resume looked impressive and promising, with many SharePoint projects under his belt.

He failed miserably on my moderate-advanced web developer assessment, skipping on nearly every single item in the assessment -- things that I think any mid-level web/.NET developer should know.

You see, the problem is not that SharePoint is inherently a weak platform or inherently un-scalable or inherently poorly performing, but that they've made the platform so approachable, so well documented, and built such a strong community of developers and developer evangelists around it, that anyone can get into it.

You don't need to know how garbage collection works or understand the difference between a Func and an Action (or even know what they are!) or what IL is.

You don't need to know how to write a generic class or how to refactor code to reduce complexity.

You don't need to know many of the higher level programming concepts of .NET or sound object oriented programming practices to build solutions on SharePoint because most of the time, you can just google it and find an example (Of course, most examples -- even the Microsoft MSDN ones -- are not meant for production code; they are merely designed to convey the concept and usage of a particular member in the library but not necessarily how to use it in an architecturally sound manner).

So therein lies the root of SharePoint's image problem: it's so easy to build basic solutions, a developer who is fundamentally weak on the .NET platform and fundamental web technologies like Javascript and CSS can be productive in many companies and even get Microsoft certified!  And then these developers are let loose on projects that ultimately under-deliver in one way or another.  Be that performance or usability or maintainability.

SharePoint is like the mystery basket on Chopped.  There is nothing inherently good or bad about those mystery ingredients but for the skill of the individual chefs who combine them through the application of experience, creativity, and technique to create a dish.  With different chefs, you will get drastically different results each round and the winners are usually the folks that have a fundamental understanding of the art and science of flavor and cooking as well as a deep understanding of the ingredients.

It is the same with SharePoint; it is nothing but a basket of ingredients (capabilities or features) to start from (a very generic one at that).  At the end, whether your dish is successful or not is a function of whether you have good chefs that understand the ingredients and understand the art and science of melding the ingredients into one harmonious amalgamation.  Likewise, it is important that when staffing for SharePoint projects, you focus not only on SharePoint, but also on the fundamentals of .NET, computer science, and good programming in general.

You can also think of it like a Porsche.  Give it to a typical housewife to drive around a track and you'll get very different results versus having Danica Patrick drive it.  Should it reflect poorly on the Porsche that the housewife couldn't push it anywhere near the limits?  Or is it a function of the driver?  Danica Patrick in a Corolla could probably lap my wife in a Porsche around a track.

The bottom line is that SharePoint, in my view, is just a platform and a good starting point for many enterprise applications.  When some SharePoint projects fail or fall short of expectations, the blame is often assigned to the platform (ingredients) and not to the folks doing the cooking (or driving).  SharePoint is indeed a tricky basket of ingredients and it still takes a skilled team of architects, developers, testers, and business analysts to put it together in a way that is palatable.


Watch Out For SPListItemCollection.Count and Judicious Use of RowLimit

Posted by Charles Chen

This seemingly innocuous call can be quite dangerous when used incorrectly.

The reason is that this property invocation actually executes the query.

This is OK if you plan on iterating the results because the results are cached, but costly if you don't plan on iterating the results.  The following code sample can be used to test this effect for yourself:

static void Main(string[] args)
    using(SPSite site = new SPSite("http://internal.dev.com/sites/oncology"))
    using (SPWeb web = site.OpenWeb())
        SPList list = web.Lists.TryGetList("General Tasks");

        SPQuery query = new SPQuery();
        query.RowLimit = 1;
        query.Query = @"
<FieldRef Name='Title'/>
<Value Type='Text'>500KB_1x100_Type_I_R1</Value>
        query.QueryThrottleMode = SPQueryThrottleOption.Override;

        SPListItemCollection items = list.GetItems(query);

        Stopwatch timer = new Stopwatch();


        Console.Out.WriteLine("{0} items match the criteria.", items.Count);

        var timeForCount = timer.ElapsedMilliseconds;

        Console.Out.WriteLine("{0} milliseconds elapsed for count.", timer.ElapsedMilliseconds);

        foreach (var i in items)
            Console.Out.WriteLine("{0} milliseconds elapsed for start of iteration.", timer.ElapsedMilliseconds - timeForCount);


(And of course, you can check the implementation of Count in Reflector or dotPeek)

You will see that the start of iteration will be very fast once you've invoked Count once.

Now here is where it gets interesting:

  1. The total time it takes to execute the query is longer for invoking Count versus just iterating (~3000ms vs ~3200ms, about 5-10% in my tests).
  2. When I set the RowLimit to 1, I can reduce the time by roughly 40-50% (~1600ms vs ~3200ms for a resultset of 230 out of a list of 150,000 items).

Try it yourself by commenting and uncommenting the RowLimit line and commenting and uncommenting the line that invokes Count.

What does this mean for you?  Well, if you don't need the count, then don't use it.  It's slower than just iterating the results. Where you plan on iterating the results anyways, don't invoke Count. If you need the count, you are better off doing a counter yourself in the iteration.

And in a use case where you don't plan on iterating the result set (for example, checking to see if there is at least one occurrence of a type of object), be sure to set the RowLimit in your query!


Is Social for the Enterprise Useless?

Posted by Charles Chen

There is a key difference when we look at social networks in our personal lives (Facebook , Twitter, etc.) and professional lives (LinkedIn) and social networks in an enterprise and that key difference is that enterprises are still primarily concerned with getting work done.

I've already given my thoughts on it before: I think enterprise social is more or less useless for most employees in a corporation.

Wired has a good opinion piece on this:

If we sat down and read every email in everyone’s inboxes, took notes in every meeting, lurked in every chat room, and then carefully kept everything up to date, we’d be able to answer questions like, What are all the steps left between now and the next project? Who’s responsible for each step? Which tasks are high priority, and which can wait until later? Where are all the files and conversations needed to do this particular activity?

Or, Why did we decide that thing six months ago that’s affecting what I’m trying to do right now? Heck, What should I be working on right now?

But no one is able to read/note/track/lurk on everything. Even if they could, it’s soul-sucking (at least, it was for me). And this work about work — and the resulting confusion around not knowing what’s expected of us — contributes to disengagement, resulting in billions in lost productivity. Every year.

It seems crazy that 99% of companies lack a single place to track all of this, a definitive source of “truth” about everything they’re working on. Crazier still given that $304 billion will be spent on enterprise software this year, much of it — like enterprise social networks — purporting to solve these problems. The problem with many of these approaches is that they’re just ports of earlier technologies designed for connecting people, not for coordinating work.

Yet there’s a way to work together with less effort, and it requires harnessing the work graph. Whereas a social graph maps people and their relationships, a work graph centers around the work.

I think the bolded is the key; what enterprise needs today isn't necessarily tools to connect people -- there are plenty of those already -- but better tools to coordinate work.  What enterprises need is a way to streamline how work gets done and -- sure -- part of that is connecting the right people, but part of that is being able to then coordinate the effort without introducing too much process friction and overhead.

By and large, most of the teams I work with from Fortune 500 customers and clients as well as tier 1 consulting companies still rely on positively antiquated processes and software to manage coordination of work that are heavily wrought with impedance.  Microsoft Project plans and Excel spreadsheets are some of the absolute worst tools that one could possibly choose for planning, managing, and coordinating modern software projects and yet they are still the bread and butter of many teams (maybe that's why "On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted").

I find that most of that is a result of the simple fact that project managers in your typical enterprise project are likely to be more senior folks who moved on up from their prior positions that are somewhat set in their ways and their tools.  Software and how we interact with it has evolved dramatically over the last decade (think about it, Facebook didn't exist 10 years ago) and yet many project managers have not evolved their thinking and how to utilize more fit-for-purpose software for coordinating work; they have stuck to their guns and carry over legacy Excel spreadsheets and Microsoft Project plans that are simply too unwieldy for fast-paced, day-to-day collaborative execution of work.

Just as cloud infrastructure is beginning to shift how enterprises rethink IT infrastructure, will we see a similar shift in how teams coordinate work?  If it comes, I think it will look far less "social".

Thinktastic TeamPoint is one crack at solving this problem of coordinating work by integrating chat with real-time notifications linked to project artifacts (tasks, documents, milestones) to create a real-time, contextual, workstream that allows teams to view progress, broadcast status and in-progress work, as well as provide greater visibility into the overall health of the project.