Month: July 2010

When transparency becomes overload

Lately I’ve enjoyed Eric Brown’s blog. In his entry Links for July 25 2010, he links Gartner analyst Mark P. McDonald’s blog entry Transparency creates an information blizzard not an excuse, nor an absolution.

Mark waxes on transparency, but I am not sure I agree with how he constructed the story.

I would have just gotten to the point: Transparency is only a first step. It is not the end. The goal is meaningful information in the hands of customers/users, allowing them to make informed decisions.

Transparency overload is real. It’s like mortgage applications. Thanks to laws and political pressure, mortgage applicants are avalanched with useless data.

Mortgage applicants don’t need a ream of trees. They instead need three data points:

  1. Does this mortgage conform to industry standard expectations for a mortgage of its type? E.g., does it have a fixed interest rate, no early payoff penalty, standard ways to calculate interest and principal, etc.?
  2. How much is this mortgage going to cost me each month?
  3. How much am I paying upfront to get this mortgage.

Seriously, that’s about all most borrowers really need to make an informed decision. But we’re inundated with information, and this info overload can be a tool for a lender to slip in some really odious terms. (“Hey, you knew about it, it’s right here on paragraph 16, page 47!”) I call it “transparency gone wrong”.

How am I applying this in my own life? I work in a department that wants to improve its transparency, but its tools and procedures are still developing. This is a double edged sword.

I am managing the technical side of a large project. I have many users who need “just enough” transparency. So I am creating my own rules, establishing my own tools, while seeking the right balance between useful transparency and overkill. It’s more challenging than it looks, but I hope it helps the department’s transparency maturation.

PowerShell’s 248 or 260 character limit path bug

Thanks to bad, old code, Microsoft’s PowerShell breaks on file or directory paths longer than 248 characters. PowerShell reuses other code that maintains compatibility with very old software that can’t understand paths with more than 260 characters. I don’t know how 260 drops to 248 in PowerShell, but it does.

Amazingly, in the first comment in a bug report, Microsoft dodges the question and passes the buck.

I hit this bug when working with a Sitecore web site. For example, I have a path like this:

C:\XXXXXXXXXXXXXXX\raw\WebSite\App_Data\MediaFiles\{11111111-1111-1111-1111-111111111111}\{3D6658D8-A0BF-4E75-B3E2-D050FABCF4E1}\{15451229-7534-44EF-815D-D93D6170BFCB}\{700C2C14-6082-4378-AA43-821E8422E9BE}\{6507E0E5-6CF2-4342-A11F-68F787B32EA3}Boulevard.jpg

That is 259 characters. I can’t delete it with PowerShell’s Remove-Item command.

Fortunately, there is a workaround: use legacy command prompt tools. In my case, I am trying to remove everything below C:\XXXXXXXXXXXXXXX\raw\, so I can use this command in PowerShell:

cmd /c rmdir C:\XXXXXXXXXXXXXXX\raw\ /s/q

But I shouldn’t have to do this. There is no reason that PowerShell can’t delete files with more than 248 character paths.