Why microsoft docs and systems suck so very, very much

In case you can’t tell from the title of this post, I’m in a rant. I’ve been building up this rant for a good hour now, having spent it reading through Microsoft TechNet, Channel 9 feeds, and other places trying to figure how what it’ll take to solve what I perceive as a simple problem.

I’ll start by answering the question I pose in the title:

Microsoft makes simple tasks unbelievably complex and arcane.

Here’s what I’m trying to do, and what led me down this primrose path:

  • I want to collect some data in a database. In this particular case, the data is CPU utilization metrics for a number of servers. Each row of this nifty data set is the mean “% utilization” of a server for the past 5 minutes.
  • For all the servers, I want to roll up that data and know what the 95th percentile peak of the usage is over a month.
  • Now I want to use that number as a “KPI” and report it in SharePoint 2007. Why SharePoint 2007? Because I’ve been asked to use it.

I thought “OK, how hard can this be?”. My thought was maybe I’ll put in a SQL statement with parameters somewhere in a form, add in some connection information, and away we go.

Nope. It’s quite hard apparently. From what I can tell of the documentation available in TechNet, I should have a Microsoft SQLServer database somewhere with a couple of things installed. Their Analysis services most particularly. Then I need to install Microsoft Visual Studio so that I can create a reporting cube to which I can link in the SharePoint system. I’ll also apparently need SSIS so that I can reach into the Oracle database where this data is already stashed and pull it into this cube setup.

From the descriptions, tutorials, and how-to’s on TechNet, I’m guessing this should be considered the work of 3 different specialists (SSIS, SSAS, and SharePoint) all working in conjunction and with requirements for the data, what’s a fact and dimension, where the connections should be set up, etc. Oh – and toss in a SQLServer DBA to manage the SQLServer instance, but that’s all background.

Why isn’t this one person’s half-day effort?
Assuming I know the data and the SQL to generate my “KPI”, you’d think that this could be a pretty straightfoward thing…

As much as I’d like to diss on SharePoint for being crap, SharePoint 2007 looks pretty reasonable in it’s linkages and options for doing this “KPI dashboard” thing. It’s when you start to reach back into something other than an Excel spreadsheet or a list managed in SharePoint that this world gets unbelievably complex and arcane.

It will take me longer to create this solution than it will to write a bit of CGI with SQL and hook it into a free charting widget and shove that up onto a website. ARGH!!!

Published by heckj

Developer, author, and life-long student. Writes online at https://rhonabwy.com/.

2 thoughts on “Why microsoft docs and systems suck so very, very much

  1. Interesting. Microsoft never officially states it as such, but they have their own philosophical approach to software, services, and documentation. I haven’t thought this through all the way, but: It’s something like: Their stuff is designed to make the *intended* use easy, and often bulletproof. But, as you move outside their design parameters, the required effort goes up *way* faster than it ought to. I don’t know if it’s really asymptotic, but it can seem that way. I’ve sometimes had the same reaaction you did: It just CAN’T be this hard to do what I want to do, can it?

    I do think their software universe has some ancillary issues that do not help. Microsoft products’ data files are usually (always?) binary, and are usually one single large file rather than many small files. This makes it hard (sometimes nigh impossible) to find, and then get at, your data. (Exhibit A: The Outlook .pst file.) Then there’s the lack of documentation for their file formats and interfaces, because they’re all proprietary. Their (admittedly excellent) support of legacy software and hardware is great for some end-users, but it complicates everything. And their “we eat ONLY our own dogfood” approach to software development means they won’t document about how to hook up something to, e.g., MySQL because, gee, there’s no point to doing that when you can run SQL Server.

    I feel your pain.


  2. I don’t know anything about working with SQL, but your post lights up one of my rant buttons as well — on spreadsheets. It seems to be a similar problem, having some data and finding a way to generate what you need to know from it. Excel makes you think about the problem like it was on a piece of paper, rather than the dynamic system that is *software*. I’d love to some software focus on speed, experimentation, and building of systems which you can push, pull munge together to find the data you need.


Comments are closed.

%d bloggers like this: