Imagine the case now where your internal departments insist on purchasing a poorly secured application.  Happens all the time – except now, this poorly secured application is outside the corporate administrative domain.  Will your corporation have the infrastructure, the involvement, and most importantly the policy prepared,  such that your requirements for security and identity are considered at the time of purchase, instead of bolted on after the fact?

Well, don’t worry.  Neither does anyone else.  Think of it this way.  You’re the star in a fairy tale, and you’re using a time-honored method for ensuring your happiness:  one that allows for the greatest amount of suspense and possibility for evil to win.   After all, everyone wants their corporation to be part of a thrilling epic saga, do they not?

Sacrifices of assurance for end results are the things of fairy-tales, after all.  Did Prince Charming put out an artist’s rendition of Cinderella’s face to find her?  No, he offered to marry any girl that could fit a slipper. Hijinks ensued. If we allow these new web-based applications to grow into large communities before we dictate that it is not acceptable to use standalone user management pages stored in silos and protected by flimsy HTML form posts,  we will bring the very problem we already have today in both the consumer space and inside the Enterprise into a much more dangerous arena.   If we choose to draw a line in the sand now, web and cloud based  companies pursuing the Enterprise market will gladly make changes to draw in initial customers, assuming we all make a unified, logical, and complete case.  If we wait, however,  the need for application content will again outweigh the need for safe infrastructure, and we will have lost our leverage.

Those of us who wish not to see the sins of our past revisited, the time is now.  The tech is there, but it isn’t easily consumable by potential applications.  We need to get our act together;  if we do, we can avoid the next chapter of drama.   Otherwise, well, there be dragons in our future.  Why slay them later, when we can simply keep them from ever coming to roost?

Here’s what I’d like.  I’d like a choice of two automatic update modes.  Bleeding Edge mode is for developers and people who care more about the means than the end, or who like to sound the alarm when something goes wrong.   Nice & Easy mode is for people who are happy to wait 5 days and know that everything will just work.

Wouldn’t that be nice?

I want a way to put a sunset date onto technical web data,  so that I can find relevant technical information instead of the one “Introduction to Tomcat” that 5 gzillion people downloaded 6 years ago, and that eventually reveals itself to be 3 versions out of date, but still shows up at the top of the hit list.

I would love to have a way to know that when presented with two webpages, each describing two COMPLETELY different ways to do something without mentioning a date or a version or a platform, I can pick the one that isn’t going to waste 6 hours of my time.

Scope.  Context.  That is what I wish for.    A consistent way to determine scope and context.

This is my own reminder to myself, to write documentation that includes scope and context, right up front.  Whatever I can go back and add scope to, I will.  I will imagine that it is 10 years from now, and .NET Framework 27.2 has just been released,  and I want to put that on my machine along with Higgins Framework 10.7b.    Either my documents should be still-relevant, or instantly dismissable.  If I can accomplish that, and keep it up, I’ll be happy.

The worst documentation is the vendor-branded stuff, of course.  No author.  No date.  No version.   Erg.