5 Creative Ways to Settle Office Disputes

We've all been in the situation where two people strongly disagree on which direction to take with regards to a business or technical strategy.  One vendor or another.  One process or another.  One policy or another.  It can become very emotional at times, and often leads to lost productivity and bad feelings that can linger on for days, months or even years.  In many cases, the lingering emotional scarring can impact productivity and quality of services for everyone involved.  Well, there are some semi-proven ways to deal with these situations in professional, productive and positive ways.  And who doesn't like a gosh-darn 3-P solution to a problem?  Huh?  Golly.

Here's a short list of five (5) suggestions that might help improve the situation and make everyone feel better enough to give each other a big sloppy kiss, without any hidden sharp objects.

Tip 1- Jello Wrestling with a New Twist

This one works great regardless of the gender bias that may exist in the room.  Everyone has to consume 1 gallon of Jello powder mix, then drink a 1 liter bottle of soda, and then get in a ring and beat the living crap out of each other.  First one to puke all over their opponent, wins.

Tip 2 - Paperwork Shuffle

Everyone in office environments likes to brag about how they suffer with the most paperwork, email, IM calls, voicemails, and so on.  Perfect examples of "first world problems" if ever there were any.  Imagine trying to elicit tears from a starving mother and her starving group of babies, too famished to swat away the incessant swarm of flies and mosquitoes.  They will pity you for sure.  So how about putting your money where your mouth is, and challenge the opponent to produce enough evidence to back it up?  The one who shows up with the most weight (use an approved scale obviously), wins.

Tip 3 - Marching Band

When the other person won't shut up, start humming the tune to something familiar like "Glory Glory Hallelujah".  Start quiet at first, then gradually bring up the volume until you can barely catch your breath in between gasps to belt out that next glorius bar.  Bonus points can be earned by pretending to march in formation, by yourself of course, around the conference room.

Tip 4 - Zen

When the other person continues to argue their point, refusing to hear your side at all, just stare at them without blinking as long as you can possibly manage.  Never, and I repeat NEVER, blink or look at anything else in the room besides their eyes.  They are like source of energy.  Feed off of them.  If you can stare at them long enough, one of two things are most likely to happen next: (1) they will call security for help, or (2) they will scream like a wounded baby and run down the hall as if zombies are trying to eat them.  Either way, the original problem should now become moot.

Tip 5 - Levity

When violence fails to solve a problem, humor often stands a small chance of working.  That's what most of the infamous world fascist dictators would say, or so I've heard.  Try this instead of a gun or knife:  When the opponent begins to raise their voice and shake their head in disagreement over some aspect of the topic at hand, start stripping off clothing until you're only in your underwear.  Not all at once, but remove one piece of clothing after each time they speak a phrase in disagreement.  When they finally realize what's happening, look at them and wait.  If they remain silent, offer this, "if you stop now, I win.  If you continue on, I will have to add whipped cream to this and keep moving."

If you try any of these out, be sure to post a comment below to let us all know how it worked out?  We'd love to hear your thoughts on this.  Have a swell weekend!

Why Every SysAdmin Should Learn to Write a Script

I'm a bit overdue for a perceptual conceptual brain-twisting deep-dive article, and caffeine seems to always push me in that direction, so it was time.  And besides, I've been torquing my brain to the limits working a huge article series for 4Sysops on Troubleshooting Configuration Manager clients.  On top of that I'm in the final throws of my next book, and no shortage of "real" work at the office to contend with, and trying to maintain sanity with four kids still at home, and well, it'll be worth the wait, but I may need a stiff drink when it's wrapped up.

So, without further adieu...

Why the Title?

There's no shortage of articles, blogs and whatnot that tout the "benefits of scripting and coding" for anyone who spends time on a computer.  Okay, maybe they're mostly aimed at those who earn a paycheck spending time on a computer, but that's okay too.  Most of the articles I've read however seem to focus on the benefits of automating common tasks, as well as extremely difficult or complex tasks.  That's fine also, but there's more to it than that.  Much more.  To me they're kind of missing the main point:

Writing a script teaches you a particular way of thinking.

Sure, automating tasks pays pretty well, but there's more to be gained by an everyday computer technician from learning to write even the most basic script. One of the main reasons, indeed THE reason, that I chose the title for this article has nothing to do with automating tasks at all. Let us drink the Kool Aid of digression and digress with me for a bit, mmkay?...

A Different Kind of Thinking

Writing software code, whether it's to be compiled or interpreted, involves a process of thought.  Granted, there are some variations of the thought process as it pertains to a particular programming language, as well writing functional, procedural or object-oriented code, but the process itself; the process of telling the computer to perform certain actions, remains.  It's a logic process.

If This is True: Do That  /  Otherwise: Do something else...

Disregarding semantics for a moment, the flow of logic is roughly the same whether you work with C++, JavaScript, LISP, Python, Ruby or whatever.  Picture the following example scenario:

Task: Instruct a Robot to retrieve a box of cereal from a cabinet on the other side of the room.

That sounds easy, right? "Hey, robot.  Get me the box of cereal."

But the robot doesn't move.  It needs to be told:

• where to go
• how to get there
• what exactly to retrieve
• how to actually retreive it
• where exactly to go next
• how to go to the next location
• when to perform each step

The only basic questions it doesn't absolutely need to ask are the who and why aspects. For now, anyway.  Let's ignore the possibility that it's a super-advanced robot that understands these things. Let's instead go with a robot that was just born and has to be taught like a baby human would.  These steps come with a few qualifying pieces as well:

• where to go: relative to current location
• how to get there: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• what exactly to retrieve: which object(s), means for identifying or locating
• how to actually retreive it: grasp, slide, push, pull, tip, scoop / carry, store, clutch
• where exactly to go next: relative to current location
• how to go to the next location: walk, roll, crawl / turns, ascentions (climbs),descentions, and distances
• when to perform each step: now/immediate, x minutes/seconds from now/from previous step

It should make you pause for a moment and begin breaking down the sequence of tasks in detail:

1. Turn [n] degrees to your [right/left]
2. Move forward approximately [x] feet and stop
3. Turn [n] degrees to your [right/left]
4. Move forward approximately [x] feet and stop
5. Raise arm upward to [x] degrees from default position
6. Extend arm forward [x] inches
7. Grasp cabinet handle
8. Pull grasped handle, swing arc to [left/right] until door is opened [x] degrees from starting position
9. Release handle
10. ...

You get the idea.  Those of you that have actually programmed machines like this already know that I'm glossing over a lot of detailed steps in between.  This is actually the basis for how a programming language is developed: step by step, nouns and verbs. Then come the adjectives (gently, loud, etc.), until the language is matured enough to accomplish the general class of tasks it was intended to address.

Side Note: When asked "what is the best programming language?" the answer is: "There is no such thing as a 'best programming language'".  Every language is better at some particular tasks than others.  A programming language is a tool.  A tool is a means for accomplishing one or more tasks. Each tool is conceived and built to address a particular set of tasks.   

Contextually, some languages are "better" to master with regards to job opportunities or specific projects.  From a technical point of view, the concept of "better" depends on specific comparisons of individual features as they align with a set of specific tasks which are to be accomplished.  The more general or multi-purpose capability a particular tool becomes, the less specialized it becomes at the same time. 

That was a lot of mumbo-jumbo, sheesh.

You may start letting your mind wander into additional challenges, like navigating stairs, odd angles, and so on.  Hopefully another thought crossed your mind: How much we, as human beings, take for granted this little stuff.  Imagine what someone fighting through physical therapy has to deal with as they learn to walk or speak again following a major injury.

In most respects, this way of thinking forces you to shoehorn your intentions into the mouth of the beast we call a computer. The point is that when you're forced to structure your thinking in someone else's terms, it also forces you to think more clearly about what it is you're trying accomplish.

In many respects, it forces you into a serialized or sequential mode, even if your goal requires solving parallel processes.  You have a Start and a Finish.  A beginning and an end.  Initialization and termination. An Alpha and an Omega (for you religious folks, a little humor, pardon me). Regardless of having to contend with seemingly random or asynchronous sub-tasks, the overall context has (or should have) a defined start and end.  If you're looking to run a program that just goes off and does a bunch of unrelated things; does a lot of unrelated and undefined things, and never ends, that's been done already: It's called politics.

Let's put this into somewhat of a "real world scenario" for a  moment. A

Example: Finding all Files in a Folder that Contain a Particular Text Value or Numeric Pattern

This is a very common task indeed.  Whether it's finding documents that contain a reference to a particular contract number, or data files that contain a numeric pattern, or sales records with a particular date, log files that include a specific name or code, the logic for pursuing the answer is pretty much the same.  What differs is the trivial stuff like formats, locations, and the periphery like environment and concurrency limitations.  I say "trivial" in the sense that those are relatively less important than the primary goal being sought.  I'm fully aware that in many cases those so-called "trivial" extraneous things can become the biggest headache to deal with.  Okay, enough blabbering from me.  Let's dissect this creature...

What are we trying to accomplish here?

1. We need to identify what we are looking for: ____
2. We need to identify where to look for it: ____
3. We need to identify what to do when we find it: ____

There are millions of other things we can do, and may need to do, in addition to these basic questions, but in most cases these are the three most important questions to answer.  You could boil them down into two primary categories: Target and Action.  What is the target and What action do we take on it (or because of it)?

For this example, we'll keep it simple and go with the following parameters:

Find all instances of the text value "CNX-10114025" within all of the documents contained in the Folders located on server FPS0025 under the shared folder root of "Contracts".  The target UNC path then becomes "\\FPS0025\Contracts".  Maybe a quick inspection of the folder structure reveals that there are nested folders which will need to be scanned, as well finding that there are an assortment of file formats to be found:

• Microsoft Word, Excel, of various versions (.doc, .xls, .docx, .xlsx, etc.)
• ASCII Text (.txt)
• XML files
• HTML source files
• PowerShell scripts (.ps1)

You probably stared at that list and immediately began to think through the process for opening, reading, and parsing each file type.  You're already staring at the trees, let's get back to the forest.

Here's what you should have thought:

1. Access the root folder
2. Look for files in the root folder
3. Check each sub-folder
4. Look for files in each sub-folder
5. Check for the next level of sub-folders
6. Look for files in each sub-folder
7. Wash. Rinse. Repeat

An average programmer or scripter (script-writer? script-kiddie? I can never figure out what the proper term is anymore) would get to step 4 and immediately blurt out "Recursion, bitches!" and then quiet down after realizing they just upset everyone else in the library.  I happen to be sitting at a table in our "central" public library actually, so that's why I made that connection.  I haven't blurted out anything yet though.

Forget recursion for the moment; stay focused on the forest.  The trees will come later.  And, yes, I know that the preceding sentence is completely illogical, let's keep moving along...

Are you seeing the process yet?  If you're following along with my mindless rambling, you're probably nodding in confirmation of understanding that you have to think it through in an orderly fashion.  The key here is "orderly" (i.e. sequential.  serialized.  linear).

Side Note: Yes, I know that there are non-linear, amorphous, parallel and even polymorphic/non-linear/parallel problems to be solved, but this is Dave 101 and that course isn't until next semester (if ever).  Context is everything.  The context here is: how does writing a script benefit a systems administrator who's never considered writing a script before now.

Pseudo-Code to the Rescue

Most programmers will have likely put there head into both hands and moaned at reading that line above.  The prevailing view of pseudo-code is that it's for beginners.  Noobs.  Training-wheels.  And in some respects that's true, but it works. No reasonable programmer or scripter can argue that writing pseudo-code is detrimental to anything besides (A) their ego and (B) their time.  I've seen it used by some of the best and brightest programmers when conditions were sufficiently warranted.  What did that mean?  I mean that when faced with an incredibly complex task to accomplish, pseudo-code can help map out the primary steps and it can bring clarity to the major components of the impending code to be written.

What is Pseudo-Code Anyway?

Rather than explain it, I'll just show it:  First, here's a chunk of actual program code...

If Not amx_InstallRegKeyExists ( regKey3 ) Then
   dPrint "info", 0, "AMX is not installed. Proceeding with install sequence."
   If Not amx_PreReqsFound ( arrReqIDs ) Then
      dPrint "info", 0, "Installing AMX prerequisite components..."
      p1 = amx_InstallMissingPrereqs ( arrReqIDs, False, vbMinimized )
   Else
      p1 = True
      If amx_InstallSequence ( arrAppIDs, False, vbMinimized ) = True Then
         p2 = amx_InitRebootSequence()
      Else
         dPrint "error", Err.Number, Err.Description
      End If
   End If
Else
   dPrint "info", 0, "AMX is already installed. No action required."
End If

Now, let's write that in pseudo-code:

1. If application "AMX" is NOT already installed (then...)
1. install prerequisite software items
2. install AMX application
3. check that everything installed properly
4. reboot the computer
2. Otherwise (else...)
1. nothing to do, exit cleanly

That's it.  Pure and simple. Now, the question you may ask is "Hey, dumbass: where do I buy a book on this 'pseudo-code' programming language?".  You don't.  You can't.  There's no such official programming language by that name.  It's a term used to describe the writing of program instructions in human-readable terms. It's like a "faux diamond", "pleather jacket", or an "honest politician". It's "fake". The word "pseudo" means "not actually, but having the appearance of...", or fake, so you get the picture.

Master or Commander?

Am I saying that you need to spend a lot of time mastering the art of writing scripts?  No.  I'm only suggesting that learning how to write even one script successfully will help you in the long run.  It's sort of like walking a mile in the computer's shoes.  I'm not going to trick you and deny that writing scripts isn't both addictive and lucrative.  The more you write the more tasks you'll think of to use them on.

Pointers

Some of the sites I look to for help and inspiration when working on new scripts (if I don't have code laying around from twenty years of tinkering with it):

• Microsoft TechNet Script Center
• PowerShell.com
• Rob van der Woude
• PowerShell Code Repository
• ss64.com 
• Dr. Scripto's Script Shop (Microsoft)
• MSDN VBscript Language Reference
• MSDN ADO Code Examples
• ActiveXperts.com

Writing for 4Sysops.com

I may have mentioned it before, but I've accepted an offer to write articles for 4Sysops.com.  So far, I've submitted two multi-part articles:

• SCCM Right-Click Tools - Part 1
• SCCM Right-Click Tools - Part 2
• SCCM Right-Click Tools - Part 3
• Configuration Manager - The Evolution of Security - Part 1 (coming soon)
• Configuration Manager - The Evolution of Security - Part 2 (coming soon)

You may be wondering (all three of you who read my blog) what impact this may have on this blog.  Or maybe that question never crossed your mind.  That's ok, I'll pretend you were wondering about this and I will pretend to address your pretend concerns.  Mmmkay? :)

First, I will continue to post things here on this blog.  Things I find interesting and, hopefully, you find interesting as well.  I will at least shoot for "peculiar" if I can't attain "interesting", but either way, I will do my best to entertain whilst shoveling loads of techno-babble into your eyeballs.

Second, 4Sysops.com will get first dibs on upcoming topics.  That way I don't create any conflicts with our agreement.  Contracts matter, after all.  Most of what I submit to 4Sysops.com will be purely technical in nature.  Most of what I post here will be a mix of technical and philosophy, with a pinch of stale humor thrown in.

Third, I really don't have a third.  But I will try to avoid confusing readers and do my best to cross-reference things so it doesn't become a chore to access content on either site.  I hope this works for everyone.  After all, trying to please everyone always works well.

It's About People

With all the talk about Romney saying that a "corporation is a person" or whatever, I got to thinking that there's a twist to that which is actually very true: A business is really about the people within it.  I'm not bringing this up to be political in any way whatsoever.  Seriously.

It sounds simple, right?  It seems obvious enough.

But how many times do you hear people around you say something about a business, or an organization of some kind, either negative or positive, and they apply their judgement against the name of the business?  I hear it all the time. A great example is cell phone companies.  Get a conversation started about which company is "best" (whatever that really means), and watch the fur fly.  I've heard things like "Verizon sucks!" and "ATT is crap!" or "Don't even waste your time with Spring or Intelos", and so on.

I like to ask: "Why?" - then when they try to offer up some generic bullshit story, I cut them off with "who was that?", with the intent of drilling into the fact that it's usually isolated experiences with specific people that build the perceptions we hold about companies.  The same is true for any organization, even governmental agencies.  Everyone is negative and lays their judgement on the doorstep of the entire organization, when in fact they can't really back up more than one, two or three individuals in that organization that affected their views.

When you think back to any job you had in the past, you probably conjour up a mood or "feeling" about it, based on memories.  Good or bad.  But when you focus in on those feelings, you can almost always nail down who the people were that shaped your fondness or dislike of that job.  Maybe it was just one person.  Maybe it was a group, but often that group is shaped in cultural terms by one person, maybe the leader, whatever.  It's still people.  It's always about the people.

This week I was told that one of the guys who sits near me at work had given notice and was leaving.  He has been at this place for more than six years, and is very well liked.  One of the nicest people I've ever known.  It bummed me out the entire day, knowing he'd soon be gone.  Not "gone" in the ultimate sense, after all, with social networks being what they are today, it's hard to disappear from the lives of your colleagues like was the case five or ten years ago.

Still, as I approach fifty years of life on this ball of dirt and water, I've learned how important people are around you.  How vital they are to shaping our daily lives.  From the littlest of things to the major things, the people you work with every day set the mood for how you wake up, and whether you look forward to going in to the office, or not.  And as I've seen many good people leave places I've worked at, I become more attuned to the value of nice people, talented people, helpful people, and how important they are to everyone around them.

This isn't really about this one guy, it's really about all the great people I've worked with in the past few decades.  I'd like to think I was one of those "good" people that was missed when I had left one place for another, but that's not for me to decide.  I'd have to ask them, but a good part of me feels that the smartass side of my personality probably didn't leave too many sad people behind as I moved on to a new job.  Who knows.

What I do know is this: If you work with people that frustrate and anger you, or just annoy the shit out of you a lot, avoid them.  It's more important to focus your time on the people that make you smile, who inspire you, who make you feel good about going to work instead of dreading it.  Because it's really all about people.

If You Watch One Video on this Site...

You need to watch this one.  Gary Vaynerchuk has been around for a long time, even before Wine Library TV, he was a mover and a shaker.  A brilliant guy.  Pardon the language (NSFW), but the message makes the f-bombs forgettable.  Enjoy!

Database Digressions and Developmental Digestion

Put on your caffeine hat and come with me on a voyage into the ethereal world of nerds versus geeks.  That's the party peel-off sticker I'm slapping our foreheads, written with a blunt Crayola crayon.  With enough alcohol and caffeine it will all make sense soon enough.  Let's go...

I would venture to say that 99.99 percent of software development projects, probably even software development organizations, are arranged into de facto groups that place the application "coders" in a separate function from the database folks.  The problem this has created has been legendary.  It's not only led to human behavioral issues and philosphical approaches to address such structural idiosyncracies, but it has also led to mechanical approaches, such as LINQ and XPATH, and so on.  Trying to fit automation processes to human processes is always a challenge, on a good day.  When the human process is broken, it's a disaster that unfolds slowly and often at an incredibly high cost (both in terms of time and money).

Did i say INCREDIBLY high cost?  Yes. Incredibly high.  The problem is that it's almost always a secondary, or tertiary cost.  The kind that don't stand out in distinction on a balance sheet, so they often hide in the margins.  Those are what often lead to bad feelings between IT groups and the Financial groups.  The main reason is that the Financial folks are left to ponder where these strange, nebulous cost creeps are coming from, while the tech-minded IT (Dev) folks are rarely prepared to articulate and quantify them adequately.  They may indeed "know" where they come from, but cannot communicate it in the language of Finance, so they shy away from it, making the problem worse over time.  This is analogous to a couple that don't discuss sensitive issues because they know they will always turn into an argument.

Mechanical Aspects

I'm digressing into the human/financial aspects.  But what about the structural and mechanical aspects?

I have mixed feelings about things like LINQ.  It's technically a very clever, impressively creative approach to translating mental processes from one world to another.  But at the same time, I've rarely seen die-hard DBA's embrace it over traditional SQL/T-SQL, so the divergence is not only mitigated, but elevated with yet another wedge driven into place.  A classic example is when a Dev guy walks over to ask for help with a complex SQL query that was coded in LINQ (or anything other than T-SQL) and the DBA looks at it and says "Sorry.  I work with SQL.  Can't help you."  I am aware there are exceptions to this scenario, but they are "exceptions", not the general, majority rule, at least from what I've seen and heard.  I admit that I haven't seen or experienced every environment, so I'm obviously speaking anecdotally.

I'm picking on LINQ unfairly though. It's not really a fault of LINQ.  It's a respectable concept and the incarnation has evolved respectably as well.  It's somewhat of a situation of "blaming the messenger" when the message is the problem.  The message is unavoidable though.  The message is a symptom of an age-old broken human condition in the IT environment: divisional politics.  Not departmental, but "divisional" in the same sense as "functional", whereby the DBA and Dev folks are functionally divided.  They may be best of friends.  They may be mortal enemies.  It doesn't really matter, since they still focus on, and operate within their own distinct worlds, with their own unique languages and customs.

Bridges of Translation

If you are in a large enough organization to afford the luxury of a dedicated API group, they may be your bridge.  Having to convey the wishes of the AppDev folks with the plumbing capabilities of the server and DBA folks, they become the liaisons of different cultures and dialects.  They may even provide the abstraction that spares the AppDev team from the horrors of learning a different culture in order to cook their programmatic banquet meals.  If you're not that fortunate, it sucks to be you, maybe.  Just kidding.  Ok, I'm really not kidding, it really does suck to be in that situation.  I've been there so I'm not trying to condescend as much as sympathize.

Ramifications

The end result of these cultural divides is that databases go in one direction and code goes off in another direction.  Efficiency suffers.  Progress is stammered.  If the groups are in different physical locations (different rooms, buildings, cities, countries) it only exacerbates this further by making it too easy to cultivate an "us versus them" environment.  If you have any poison pill personalities in either group it can be gasoline on a smoldering fire, so be careful of those.

Light at the End of the Tunnel

If you can bridge the divide, it is always worth the effort.  Always.  I cannot stress that enough.  Even if pride  is a boulder to swallow, break it into smaller pieces and work on it.  Offer some concessions, some goodwill, something to prove any ney-sayers and poison pills on the other side incorrect about their assumptions about your group.  Conversation is key.  Get the people talking.  Learn what the other side has to deal with.  Maybe there are pains your group causes them that you're not even aware of.  Just learning about such things can help you refocus and make adjustments that may seem minor on your end but could be HUGE on the other end.

Making exchanges of conciliatory effort can go a long way towards building a stronger team, improving communication, raising productivity and positive outlook, and ultimately making a better product.  Quality can't happen without a cohesive group of people, and you can't bridge any divides by waiting for the "other side" to make the effort.  You often have to make the first move and meet them halfway.  Ultimately, until people issues are resolved, you can't achieve an efficient operation or efficient processes.  This is where most of the bullshit forms-bloated corporate environments grew out of.  People issues give rise to barriers of mistrust and push-back over perceived unfairness of responsibility and effort.  You can throw billions of dollars at trying to make those processes automated but if they attempt to lift the human process into a computerized process model, it will be horribly broken, and inefficient at best.

Before you ever consider purchasing or developing a system to model a business process, do some deep analysis of the process itself.  Never start with the current process as the assumption of efficiency.  In most cases it's nowhere near what it should be.  Fix the process.  Build cohesion.  Push forward, but don't drag the baggage along.  It may look frightening at first, and people will scream and complain and flip out, but if the process is re-modeled properly, nobody can argue with a better model.  Once that's done, you can translate that into software and hardware and move on to the next challenge.

Organic Architecture. Part 1

Organic - "4a. Forming an integral element of a whole" / "4b. Having systematic coordination of part" - Merriam Webster Dictionary

Most of you may assume I'm referring to the works of people like Frank Lloyd Wright, or some artist or sculptor.  Close, but no cigar, at least not yet.

I'm going to try to dive into a rather nebulous and obscure topic within the microcosm of software/systems architecture: a term one of my professors once used: "organic architecture".  He didn't articulate this in class, but he did so during a private discussion, and I've always held it in the back of my head when concocting any "solution" to a systematic challenge.  Basically, it denotes the pursuit of designing and building something that just feels "natural".

Trying to quantify that definition would be about as simple as quantifying what makes you feel love or sadness (or what my wife wants for dinner).  But I'm going to try to smoke out some constraints by example to help develop a shape to this concept.  It's going to require multiple parts in order to properly dissect this invisible beast, so hopefully you can (and will want to) bare with me on this journey into nerdville.

Organic Architecture plays a major part in many aspects of our lives and our environment.  From things we participate in, to the tools we use, and the machines we operate and travel within.  It's an inherent part of bio-medicine and chemical engineering, as well as traffic management systems and air traffic control.  It's everywhere.  Rather than try to tie a rope around something this broad in scale, I'm going to break off the tiny chunk that pertains to computer software architecture.

Why?

I really don't know.  It's raining.  My wife is on travel and the house is quiet.  I've been cleaning, cooking, eating, and hanging out with my kids, the cat and dog.  It's one of those brain-incubator environments where the mind wanders and tends to develop ideas that beg to be externalized.  Whoa! I think I just said something logical?  Maybe not.  In any case, this is one small area of software technology that doesn't get much discussion or illumination, anywhere; Not in schools, or conferences or in the workplace.  There are a few books that discuss this but most are obscure and way outside the mainstream for even the geekiest of geeks.  Typically, it is hinted at, rather than outright bagged and tagged.  Some examples I may touch on:

• Interface Design
• Systems Management Architecture
• Configuration Management Architecture
• Systems State Management
• Workflow Design
• Self-Healing Processes

Example 1 - Agent vs Agentless

You've probably heard this term before.  It's used by quite a few products and technologies.  It refers to a basic concept of where nodal processing is performed within a distributed system.  But this concept is not confined to software or technology at all.  It's used in the intelligence community, as it pertains to HUMINT versus SIGINT (geeks, you may commence to beating off over the acronyms... now!).

An "agent" in this context would refer to a component or process which runs on a remote node within a distributed system.  The agent performs the majority of processing locally. In most scenarios, the agent receives general "instructions" or control parameters from a higher "authority" or higher node in the system.  It also typically transmits the results of its processing to a higher authority or node in the system.  A biological example of this would be nerve receptors within the nervous system in the human body.  A computer example would be monitoring agents deployed as part of a systems management technology (e.g. Microsoft System Center Operations Manager®).

An "agentless" scenario would be one where nodes are not configured with any distinct autonomous processing components, but instead are acted upon directly from external/remote nodes in the system.  A social reference example of this would be cash registers in most modern shopping centers (when the power goes out, they cannot function on their own).  A computer example would be a web application, or remote systems data interrogation (think file systems, CIM (WMI), registry, event logs, etc.).

A "system", according to Merriam Webster's Dictionary, can be many things, but in simplest terms: it is a collective body of elements or components that participate in some common goal or outcome.  A football team is a system.  A McDonalds hamburger is a system.  A government is a system.  A farm is a system.

A "distributed system" is not clearly defined by any official dictionary (at least, none that I've encountered), but it basically builds atop the "system" concept to include a qualification of having elements or components which are not physically collocated or in close "proximity".

Putting all of these things together you get one of two distinct concepts for monitoring and managing a distributed collection of components:

• Agent - components are deployed to each member of the system to perform most of the querying and maintenance of the node locally.
• Agentless - members of the system are managed directly from a central node (or hierarchical layer node).

This general concept is used for all sorts of functions within a computer system (i.e. network environment).  It's used by software licensing services (e.g. Flexera FlexLM® and FlexNet®), distributed processing (i.e. 3DS Max® "net rendering"), and so on.

Summary

Why is it important or even worthy of knowing about this stuff?  Because the more you see the basic concepts laid out, the more familiar you will be to the "50,000 foot view".  The 50,000 foot view is important because it provides the most general, basic understanding of how something works.  It's how you explain something to someone else who has absolutely no insight or understanding about anything remotely related to the thing you are explaining.  It's also how you keep things in context when a slick vendor rep is pumping your hand and waiting for your signature on the P.O. after he tries to bullshit you into believing they have inventing something "radically new".

In most cases, the "radical" stuff has been around since the 1950's and 1960's (the last era when people actually used their brains to invent new things).  Ever since, most of everything labeled "new" is really a refinement or repackaging of something old.  Knowing what snake oil is, helps you spot new snake oil.

Next Part - Nodal and Agent Autonomy

Technological Peaves

I'm not OCD!  I'm really not.  But I have my OCD moments, just like everyone else does.  Mine tend to occur in phases of several hours at a time.  Other people have theirs in minutes, even seconds, or days and weeks.  And some just live their entire lives in the wonderful world of OCD.  But one thing that can trigger my OCD symptoms is looking at shitty code.  Scripting code.  Programming code. Any code.  Technicians dressed like they're heading to the Star Wars club meet-up.  Hair that hasn't seen a comb or shampoo in eons.  And I can't even remember how long an "eon" is anymore.

These are things that piss me off to no end.  I bottle it up while in the office, but once I'm around more casual surroundings it flows out of me like digested Mexican food after 4 back-to-back Starbucks Doppio Espresso's.  It ain't purdy.  And you might want to just casually walk away while Uncle CrazyNutBrain goes apeshit on his silly blog for a moment.  Ugh…

• Consistency - Yes.  It matters.  Be consistent.  I beg you.  If you bother to capitalize a variable (sentence case, word case, Pascal-case, head-case, whatever) do it everywhere.  If you don't, it says to everyone else: "I am too f-ing lazy to push my tired arm against the heavy mouse long enough to click the brick-sized 'Search-Replace' button".  It also says: "If I don't care enough about being consistent with my OWN work, guess what the **** else I don't care about?"  Suck it up - drink a few of your stupid 5 hour energy drinks and eat another bag of Skittles, whatever it takes to make you code consistently.  I bet you'd prefer your surgeon be consistent with his hands all up inside your body, wouldn't you?
    
• STOP HARD-CODING! - You spend hours writing some shitty piece of code and now you're so proud over the results you need a tissue to blow your nose from the tears of joy rolling down your face.  Awesome.  Good for you.  Now since you're so proud that you're posting it online or telling the other half-asleep idiots in the office kitchen about it, maybe you should have taken TWO more seconds to change-out your First-Grade hard-coded variables with something a little more dynamic and adaptable? Why, yes, you should.  Thank you.
  
  Instead of this ridiculous crap:  dn = "dc=contoso,dc=com"
  
  Try this, and don't even open your mouth to complain about the extra typing, just shut up and swallow that Mountain Dew you started on…
  
  Set objRootDSE = GetObject("LDAP://rootDSE")
  dn = objRootDSE.Get("defaultNamingContext")
    
• Use a Standard Document Header - Put a simple banner section at the top of all your code files that says what your stupid script or program "module" (I say that with a long, obnoxious mocking pronunciation: "maaaaahhh-dyeeeeeewweelll") is supposed to do.  Include your name and the date you were concious and sober enough to write this piece of crap, and maybe a comment about why you were able to stay sober long enough to bother writing it.  Here's an example:
  
  File: genius_module_001.cs
  Dweeb:  Dexter McFartsalot
  Date: 2423.23 (star date, of course)
  Comment:  I wrote this to calculate how much cloth I will need to buy to make a Darth Vader costume for my cat, Darth.  That's his real name.  No, seriously, I'm not kidding.
   
• Make it Readable - You may think you're the most super-genius of genius expert phenomenal masterpiece uberkind programmers, so you prefer to go Spartan with your documenting bad-ass self, but that's wrong.  Job security isn't locking people up with code they can't read.  Job security is making people WANT to use your code in the first place.
   
  If you call in sick and shit breaks, and they can't reach you, AND your code that broke can't be read by anyone that doesn't know Klingon, well guess what happens?  They start gathering in rooms to discuss how to replace your uncooperative ass, that's what.  "That friggin Joe.  Thinks his shitty code don't stink so he doesn't document it.  Leaves us dragging under the moving bus.  Well **** him! Let's start looking for a replacement that wants to work WITH us, instead of behind our backs!"
  
  In the time it takes you to go outside and smoke, as if you're "taking a break" from doing REAL work, while debating the virtues and vices of the next Tron movie with the other nerds, you could have documented your code like it was a James A. Michener novel.
   
• Keep it in Perspective - It's easy to get full of ourselves about technology and our amazing magical skills and the impact WE (as humans) have on it.  The reality is that while it helps, it's nowhere near as "amazing" as what other people do every day.  The truth is we simply arrange bits on a disk.  That's right.  We punch keys and click a mouse and move bits on a disk that cause other bits to move.  Here's a list of what we DON'T do:
     
• Save lives with our own hands
• Build physical things that outlive us
• Comfort the sick and dying (literally)
• Cure Cancer and end world hunger
• Entertain thousands of people packed into an arena or concert hall
• Entertain thousands watching on TV around the world
   
  We move bits around.  And you know what else?  You may not want to read the next line, as it may cause you to go looking for your gun and bottle of liquor:
    
  Everything we do, as computer programmers, developers, administrators, even networking technicians and engineers, will be gone before the rocking chair your dad built ever goes away.  We are in the business of the ever-changing.  The ever-evolving.  The ever-replacing.  We draw pictures in the sand.  Keep this in mind when you start pumping up the value of what you do.
   
• Context - Software, computers, routers, switches, operating systems, platforms, protocols, languages, compilers, schemas, models, are all tools.  TOOLS. They are NOT religions!  Stop debating their qualities as if they are to be worshipped.  Stop debating their characteristics as if they are truly organic and grow from nature.  "It does this",  "It does that", "It can do this" and all that.  There is no "It", all there is is "I/You/We/Us". People write code.  It doesn't grow from a tree.  I hate it when some geeky asswipe starts in with that snobbish whiny "Weeeelllll, [Windows/Linux/UNIX/OSX/BeOS/NeXtStep/DOS/Eniac] is superior because it can ___"  Shut up.  Just STFU.  Thank you.  And please, take off that stupid nerd t-shirt and go wipe the smudges off those half-inch-thick lenses, it's annoying.  Want to know why the suits don't take you serious?  Go look in the mirror.  Dress for the job and act like you earned an education.

Sorry.  I vented a bit.

I'm Starting to See a Pattern

Some of my friends reacted to that statement with "well, duh!"  But maybe I need to elaborate a little…

Job 1 - Hired as piping/mechanical systems drafter.  Got fed up with shitty program we were forced to use with AutoCAD to do niche-oriented design work.  I picked up a book on LISP and taught myself to program with AutoLISP. I wrote a new piping design program that was adopted by the department (roughly 30 users).  Soon after I was asked to write another (similar) app for HVAC, Electrical and Structural work.  Hired as a drafter, ended up being a software developer.

Job 2 - Hired as LAN administrator.  Was handed the task of managing a deployment of 300 AutoCAD installations and migrating from Novell Shitware and WFWG to Windows NT 3.51 (even shittier shitware).  Department users learned of my work at Job 1 and asked me to develop a custom piping design app for AutoCAD again.  That led to Electrical, and HVAC apps as well.  The Structure guys hated outside interference, so that was the North Korea of our CAD world of the time.  Hired as LAN admin, ended up being a software developer.

Job 3 - Hired as CAD Administrator.  Was asked to develop from the start.  Did that, by starting over and avoiding the mistakes from practices that evolved from Jobs 1 and 2.  Was handed the responsibility to manage the file servers and printers and plotters at the corporate HQ office.  That led to work in NT administration.  Took classes.  Got a cert.  Began working with automation of software deployment, patch deployment, managing user and group permissions, client configuration management, inventory reporting, license validation and long nights without sleep.  That led to coffee, beer, and more beer (followed by more coffee, of course).  Oh yeah, and tied all that together with scripting and ASP web development on top of SQL Server.  Hired as CAD Administrator, ended up being Active Directory/WSUS/SMS/SCCM manager and Web Application developer.

Job 4 - Hired as Windows Platform consultant.  CEO talks a big game, shakes hands, smokes cigars at big dinners, reassures us we're doing great, then lays us off with short notice and without having put any effort into helping our remote office get off the ground. (queue the violin music here and hand out the tissues).

Job 5 - Back to Job 2 in spirit only.  New owner of company, new environment.  Hired as Systems Administrator in the "enterprise applications" group.  Packaging and testing Autodesk applications for distribution to thousands of clients using Altiris (another department), as well as supporting end-users who foolishly called Tier 1 support thinking Tier 1 actually supports customers.  I worked in Tier 2.  Visionary boss pulls me aside after hearing I worked with ASP and SQL and begins massaging my brain cells for the good of mankind.  Hired as packager and tester, end up developing web portal applications.

Job 6 - Hired as Windows Platform consultant.  Placed in a small group to package and deploy applications using Wise Package Studio and MS SCCM 2007.  Approached by the SCCM OSD guy to help with WinPE scripting.  Soon that leads to automation scripting and building yet another web portal to allow Tier 1 to queue up computers to be imaged from SCCM OSD.  Hired as a packager, so far ___?

Conclusion

I never end up doing what it is I usually am hired to do.  In most cases, the latter role is one that appears totally unlikely at the start.  In some of these situations I was flat-out told "You will absolutely NEVER do ____" only to end up doing ____ later on.

Life is indeed interesting and predictably unpredictable.

OK, Tech Support Folks, One More Time…

Let's get this right and not have to review this again, ok?  MMmmmmkay?!

When a user (you know, those noobs we call "losers") call or email and offer up something really insightful like this…

"Uhhhh, my AutoCAD ain't working.  It just opens and crashes with some kinda error, or something."

Here's what you need to put back in their face in order to get something useful to begin troubleshooting:

1. What was the EXACT error message?  Get (them to make) a screen capture if they're too stupid to write it down or can't type very well.
2. When did this start happening? (try to get a specific day and time)
3. Did the application work properly before this started happening? (you'd be surprised how many users say they've never launched the application before… ever)
4. What has changed on the computer since the last time it worked? (this is the most painful question, because they ALWAYS… ALWAYS… ALWAYS swear, on the grave of their grandmothers, that nothing was changed.  But after a few minutes of prodding they finally fess up about the new mouse or new software they installed, or that it had a virus warning that same day, and so on)
5. Have ANY other problems been going on with your computer? (this is usually overlooked, but sooooooooooo many times I find the problem isn't with the application, but something else - see my explanation below)

If the users have even a hint of a clue, you can leverage that to pull a few more teeth:

1. Get them to check the Windows event logs

Nearly every time I have had a discussion with an IT "expert" (whatever the **** that is), if they start to bring up something about a strange application error, I ask "what do the event logs show?" - and every time (ok, 99 out of 100 times) they give me a blank look that says "oh, I didn't think to check there."  Yeah.  So much for those certification exams. (*smack!*)

Here's how I would often handle a support call:

• "Hi, this is Dave from Tech Support and I have a ticket you submitted about you not being able to print your LOL Cats to the color laserjet printer in duplex collation stapling mode from a portrait page setup rotated 90 degrees but not landscape.  Can you tell me more about what's going on?"
• (they talk and talk and talk, while I surf the web and doodle on a notepad.  Every so often I will respond with "uh huh… yeah. mmmkay…" and let them blabber some more. When they finally stop:
• "So, when did this start to happen?"
• (more blabbering)
• "And, did this ever work correctly or has it always been a problem?"
• (more blabbering and some explanation about LOL Cats and how her daughter loves them and she dressed up like one for Halloween)
• "Ok, well, I'm going to need you to log off.  Mmmkay?… and now please put on your coat and get your car keys, and I'm going to suggest you drive home and go back to bed now, mmmkaaaay?  I think we can handle it from here.  We'll call you if anything comes up, like peace in the Middle East.  Buuh-bye now!"
• Then I send the ticket back to Tier 1 with a note the says "user says Tier 1 folks rock her world and she really digs [insert name of the 90 year old tier 1 guy]"

Something like that.  Customer satisfaction is always job #1.  Ok, so I promised an example, and here it is:

Example Case

One issue that drove the Tier 1 folks absolutely insane at my previous job was a support request that described the following issue:

User says everytime they click "PRINT" or type "PLOT" in AutoCAD, it implodes" (yep, they wrote it just like that)

The Tier 1 guy would enter the ticket, and send it directly to Tier 2.  That qualified as "basic troubleshooting".  Tier 1 folks at that time were hired from one of those hospitals where they take care of vegetative patients.  They work for very cheap pay and never complain, but they also don't do a lot of preemptive diagnosis or troubleshooting.  Maybe it was all those tubes and wires hooked to their shaved heads?  They usually kicked all requests up to Tier 2, where I worked.  Tier 2 was where they hired geniuses, focused on solving the world's problems and offering compassion for the poor, displaced and brow-beaten users.  We listened to Bach and sipped tea from a fountain.  Ok, that was a bit much, I agree.

I remoted in, and sure enough, I could launch AutoCAD, do some drawing and fancy stuff (I've been known to do a little fancy stuff, at least a few times, ok, so…) then I typed "PLOT" and pressed Enter and KABOOM! the entire session vanished without any error message or warning.  Not much help.  I repeated the process a few more times and it was consistent.  But after digging around, I decided to blow away the user's custom AutoCAD profile and try it, and the PLOT command worked just fine.  Then the user went in and set their profile back up to suit their needs, from scratch (not importing it from a file), and the problem started again.

I immediately looked at the user's custom plot settings.  The profile pointed to a shared folder on the network.  So I looked in the PC3 and PMP files and found that they were pointing to a printer that was moved to a different print server, so the mapping was invalid.  AutoCAD tried to read the remote printer status and had a massive bowel movement.  Kind of like drinking four Starbucks Doppio Espresso's at once and then eating a big Mexican lunch.  Once we recreated the PC3 and PMP files to point to the correct printer everything was fine.  What caused this?

The print server folks (different department) decided to move the printers to a new server, but didn't get the word out to all the remote engineering department coordinators, who's job it was to keep their departmental PC3 files current and notify their users.  Note: a little communication goes a long way.

So, back to the story (because I know you just can't wait): Don't let users run over you with stupid requests.  You have to push back a little and make them explain things better.  You don't tell your doctor "I hurt" and then stare at him, waiting for a diagnosis.  At least I hope you don't.  You try to provide as much detail as possible - because YOUR health is at stake.  Well, make sure your users (ok, ok, "losers") understand that their support requests put them at stake.  That's a little communication that needs to be repeated every now and then.

Mmmmkay?

Review: In Fifty Years We'll All Be Chicks

This is a new book by comedian Adam Carolla.  As a confession: I have not missed a single episode of his podcast/show since it began airing.  Even the old East Indian sitar version of the Who's "I can see for miles" theme intro brings back great memories. 

Ok, those were shitty memories of riding a God-forsaken bus to work at 5:00 AM on an hour-long ride to a former job, packed between greasy mechanics and shipfitters in jump-suits nodding off in a pre-dawn coma.  Heads all bouncing and swaying with the movement of the bus.  But the podcast made it survivable.  I really, sincerely mean that.  Had it not been for Adam's show, I would've slid open the bus window, stretched my head out as far as I could and waited for a passing utility pole to take it off in a sudden thump.  I needed that show and it came at the right time.

Now, for the book: It's basically a re-wrapping of his sentiments, views, quotes, analogies, metaphors, and advice dished out as far back as The Man Show, Love Line and his current show (since inception).  Nothing at all wrong with that.  That is not meant to be a discounting.  It's actually a perfect distillation and compression of the best of that, and then some.  So if you haven't absorbed Carolla as thoroughly as you would've preferred, now's your chance.  The book is a quick read (@245 pages) but very lean and fat-free.  If you thought you were the only person who thinks The View to be stupid, you have great company.  Enjoy!

Veteran's Day / Armistice Day

This is what I posted on my lame Facebook wall today, but I need to elaborate a bit (which is difficult to do on Facebook actually).

At this very hour, 92 years ago, solders put down their guns, took off their gas masks and left the trenches after not having moved much in months. They spent the following years cleaning up, rebuilding, and trying to move on. That's what today was originally about. It's not about hanging flags out, or bumper stickers, or t-shirts or posting famous quotes. It's about the sacrifices they and their families made to push mankind farther in the right direction.

Link: http://en.wikipedia.org/wiki/World_War_I

However, reflecting over my past week of driving around the fine city of Virginia Beach, I had to bring this into a larger context.

How much do "we" really appreciate or value the service of our armed forces folks?  I mean "really".  Not lip service or gestures like bumper stickers, flags, buttons, t-shirts, ball caps, email signature footers, yard signs, ribbons, and so on.

Aside from your immediate family, close friends, neighbors and co-workers, what other veteran's do you come in contact with?  How can you tell?  Can you look at someone in the Mall or at the park and tell that they are veterans?

Then I had to contrast this with how I've seen the public respond to seeing a homeless veteran by the road, or on a bench, or sleeping behind a strip mall loading dock, or wandering down a sidewalk.  If I had to produce anecdotal statistics (ah, yes, you know how I love statistical analysis…) I would venture to say that 90 percent of folks respond by not responding at all, acting as if the homeless vet doesn't exist.  Out of sight.  Out of mind.  The other 10 are a mix of hostility or frustration.  Usually barking out comments like "get a job!" or "bum!" and so on.  I've seen people throw trash at them.  In fact, twice I've seen people with "Support Our Troops" stickers and the Christian fish sign on the back of their SUV demeaning some vet in a wheel chair sitting on the median at a busy intersection with a sign asking for money or food.  Great example.

Let's trade shoes for a minute and analyze this wonderful American behavior for a second or two…

Granted, most "veterans" statistically have not seen major combat action. Some have, for sure.  That's a given. But the vast majority served either in peace time, in combat but not immersed in bloodbath situations, or in non-combatant roles: desk jobs, clerical, logistical, bureaucratical, and so on.  But from my limited encounters with homeless veterans I've found that about half of them saw major combat, the other half either did not, or were mentally unbalanced and imagined they had served in the military (when they likely had not).

From the age of five (5) until about 23, I spent most of my weekends with my dad.  He was a physician at the Veteran's Administration hospital in Hampton, VA for thirty one years.  He ran the Domiciliary for a long time as well as being the attending physician, chief of staff, chief of ER operations, and several other roles.  I got to meet a lot of his patients.  A LOT OF THEM.  I spent a lot of time listening to them while feeding squirrels or fishing off the seawall that surrounds the facility.  I heard stories about WWI, WWI, Korea and Vietnam, as well as a dozen incidents or conflicts that nobody will ever know about (officially). 

They gave up a lot.  They get very little in return.  You might think they are showered in appreciation and special favors.  They are not.  And even if they were showered in special treatment, do you think that can possibly erase or undo memories of horrific things they've seen and been in the midst of?  Really?!  "Here solder, a shiney new prosthetic leg for you - now run along and have fun"  or "Here's two free movie tickets to show our appreciation, enjoy the show!".  Not quite the magic elixir of memory cleansing.  I don't need to share any graphic horror stories to make this point.  It should be obvious to anyone with half a brain.

In short, nobody expects you to interview every homeless person to assess their veteran status.  Nobody expects you to flip a switch and condone homelessness if you do not already feel concern.  But I do ask that you slow down and be a little patient when forming judgements and opinions based on what your eyes reveal.  Everyone has a story and a reason and reason to be alive.  You don't have to give money or food.  Maybe you can spare a pair of gloves or a sweatshirt or a happy meal.  Maybe you can spare a conversation.  If they are attacking you, that's one thing.  But when they're in a passive disposition, in a wheelchair, on the ground, laying, sleeping, hold off on gathering your angst and resentment.  If we're not out to help each other then what are we here for?

The Art of Statistical Analysis

Statistics are the infamous tool of the diabolical.  Statistics are also the crutch for the careless and lazy.  Many times you have to do your own homework to find the other half of the complete “truth” or “fact” in order to place it in proper (and accurate) perspective. 

(Just a note: I wasn’t at all excited to register for my first semester of college Statistics years ago.  But when I finished with a 4.0 I continued on with more.  I found it interesting how so much science and technique could be fabricated on top of such a murky foundation.  I think of it as a house being built where you can modify the foundation as the walls and roof are also being built).

Case in point: The NHTSA says that highway deaths were the lowest in 2009 they’ve ever been “since 1950”, and that the reduction was due to increased safety efforts by manufacturers and checkpoints by law enforcement.  [full report here]  Main points of this report were:

• 9.7 percent fewer vehicle crash deaths from 2008 to 2009
• 1.13 deaths per 100 million vehicle miles traveled
• 7.4 percent fewer drunk-driving deaths
• 5.3 percent fewer vehicle crashes overall

They based this report on FARS data from the BTS [report].

But is this really accurate?

Based on another report by the Earth Policy Institute (EPI) [report]: the number of cars “scrapped” outnumberd the number sold in 2009 by 4 million.  The total number of cars in the U.S. fell from 250 million in 2008, to 246 million in 2009.  That’s a reduction of roughly 2 percent.  In addition, the number of “fleet vehicles” fell almost 29 percent from 2008 to 2009 based on R.L. Polk survey data [report].

So, most indications point to fewer vehicles on the roads in 2009 as compared to 2008. Given a 2 percent drop in personal vehicles (potentially) and a 29 percent drop in commercial fleet vehicles, a drop of 5.3 percent in total crashes is not really all that impressive.  The 9.7 percent reduction in accident deaths is however fairly consistent within these bounds.  9.7 percent is a reasonably proportional figure.

If this is an accurate assumption, it would indicate that other factors cited by the NHTSA report really had no meaningful impact on the outcome.  Fewer people crashed and died because fewer people were driving.

Other Interesting Numbers

Another report by the Bureau of Transportation Statistics (BTS) [report] indicates that most fatal accidents involve a single vehicle, rather than multiple vehicles, and most occur on straight roadways, rather than curved roads.  Additionally, there were more single vehicle accidents in rural areas than there were multi-vehicle accidents in urban areas (where each of these categories is the predominant of their realm).  So more people died crashing their own cars into something other than another vehicle, on straight roads out in the countryside.

You’re safer driving in the city than in the country.  Those numbers are not per capita.  Those are the total numbers.  Damn.

Convergence

So, if we can assume that fewer people died in car crashes in 2009 compared with 2008, and that most people who were killed in car crashes died in “single vehicle” accidents, on straight roads, away from urban areas, AND that the most probably way to be killed is from a motor vehicle accident:

Statistically, (yes, I know how ironic it is to say that given the flavor of this article), your biggest threat to your life is you.

Conclusion

What’s even more interesting than just bending numbers or building conclusions on partial input, is how much intentional manipulation is possible (and used) after the numbers are crunched in a particular “direction”.  For example, they could say the reduction in deaths was “good” because of intentional efforts to improve safety.  Or they could say it was “bad” because it was determined by economic pressures which reduced traffic overall.  This is called “spin”.

The numbers can be selectively filtered, then analyzed with a selective lens to produce desired results, which can then be spun into being either good or bad.  Statistics is one of the most un-mathematical mathematical arts in the world.

Blog Visitor Analysis, part 1,047

Looking over my Google Analytics visitor stats, it’s pretty obvious what visitors to this blog are interested in, and that is technical stuff.  The articles and how-tos on packaging, scripting, technical procedures, and so on are what are out-performing the traffic numbers for all other topics.  If I were only interested in stats, I’d drop the hair-brained stuff and focus on becoming a tech-manual spewing machine.  But I’m not.  I would like to entertain and amuse for a second or two, but I’m not a writer, comedian or psychologist.

The issue is this:  I work with technology all day, every day.  I’m immersed in it.  Many varieties of it.  At work.  At home. So much that I myself cannot believe what I get myself into.  Just describing what I do over a given week to someone else makes me cringe at the thought that I’m just making shit up.  But I’m not.  Guilt, I suppose.  Over what, I don’t know.  But still, I could dry up and go techie from here on out and work on pushing my numbers higher and thump my chest in glory.  Who ****ing cares.  When I die it won’t matter.  What does matter is that I enjoy dumping my thoughts here, and I indeed have random thoughts.  Because I have a random brain that tries to multi-task way too much and way too often.  Rarely can I sit and think about one thing. In fact, while typing this I’m thinking about the book I’m reading and where I stopped to do this, and when I’ll stop this to do that.  This is getting really confusing. 

Where was I?  Oh yeah: I’m going to keep blabbering senselessly and sensefully in a back-and-forth manner.  At least for as long as I feel like it. Even if my stats show a bounce rate of 87% and average time on site of 1-2 seconds.  Whatever.  That’s long enough.  Stay tuned…

Be Right Back

Fighting a Cold while working insane hours on a big project.  Need sleep.  Need to recover.  I’ll be right back.

Meanwhile, I watched “Enron: The Smartest Guys in the Room”.  It boils down to this, at least from the perspective of how this impacted ME personally…

• Government was strong-armed by lobbyists (Ken Lay, Abrahmson, etc.) to relax Federal oversight (aka “de-regulate”) over energy markets.
• Enron and companies like Worldcom, Tyco and others drank their own Kool-Aid and grew into the Hulk, pushing stock prices higher and higher, artificially.
• They in-turn gave hand-jobs to accounting firms like Arthur Anderson and others to help them inflate market prices and in-turn share in the artificial margins of trading on them.
• Californians got raped like nobody’s business
• The market turned out to be a house of cards and imploded
• People at all levels of the market, the auxiliary markets, and their families and communities were pulled down in a spiral of 401-k meltdown.  Some even killed themselves.
• The government finally stepped in and realized the car was spinning off the road and nobody was behind the wheel.  Investigations ensued and eventually it was “discovered” that oversight isn’t such a bad thing.  Gee. (Personal note: If you have teenage kids, and they want to throw a party at your house, and they say to you “hey, go see a movie, you guys can trust us”, what would you do?  Ok, now imagine those teenagers are drunk on the lust for outrageous profits, insane CRAZY-ASS profits, and they want to party inside your bank account)
• The fallout yields a determination to lay down some new rules on behalf of the two folks Mr. Sarbanes and Mr. Oxley.
• IT folks are left holding the bag to implement and enforce a tangled mess of who can do what and see what between various segments of their financial departments.
• IT folks suffer with SOX compliance and no sleep.  The financial department managers go to Vegas, Orlando, or Honolulu to attend conferences, but tell the IT department there isn’t enough budget to attend MMS or TechEd, sorry.

What a sad story.  Remember to have my part played by Brad Pitt.

Now, think about this: Think that’s all behind us now?  Think again.

Weekend Thought: Do You Still Like Working in IT?

It's a simple question really.  Assuming you EVER really "liked" working in IT, or even if not in a formal IT environment, that you ever liked working with computers and related "technology".  Do you still?  On average (not just today or yesterday), do you still enjoy working in the field of technology as much now as you ever did in the past?

Me?  Not so much.

Why?  In the 1990's, the party-time of IT, things were driven by the technology itself.  The features, the capabilities, the new places to explore and improve upon, those were everywhere.  It was almost a free-for-all as far as finding problems and working out solutions with the tools at hand.  It felt like building a house or rebuilding an old car.  It was yours to conquer.

Today, it's mostly about cost cutting.  The projects aren't really driven by IT people anymore either.  They're being driven by bean-counters.  People in suits, with MBA's and PMP certifications.  People who can spew ITIL, SOX, SOA, and SDLC mantra all day, but can't write a single line of code or install a software product of any real meaning (server-based is what I'm talking about).

In the late 90's and early 2000's, if you asked most IT SysAdmins "is this product/technology something YOU would have chosen?" they would have said "Yes.  I chose it."  Today, most that I have talked with say "No.  It was chosen by someone else and I don't like it.".  Many feel that the technology they are supporting is outdated or inefficient, but they don't have the authority or backing to pursue an alternative.  Even when a proof of concept shows enough promise towards saving time and effort, most SysAdmins don't have time (or sufficient skill) at presenting an MBA-oriented business case to get it over the hump.  To us, the features save time, do more, and free us to do other things.  To the financial departments it's only a matter of how much it will cost to implement (including training and support), and what will it provide in savings and over how long.  The old ROI issue.  However, today it's less about the "R" (return) and more about the up-front cost.

Do you still go into work (or work from home) on weekends or late weeknights?  Is it by your own choosing because you LIKE what you're doing?  Or is it because you HAVE to do it?   Or do you even work into your personal hours?  Are you as driven by the fascination of what you're working with now as you were five or ten years ago?  Or are you driven more by staying employed and getting a paycheck?  If you could choose the technologies you work with, would they be the same as you are already using?

Question: What's Your Obstacle?

If you work in the IT field, or anything where you support computers, support or develop software, etc.: I ask you a simple question…

In your opinion, what is the biggest obstacle to implementing technological improvements:

Budget or People?

Another Top 10 Essential IT Skills

Brian Posey posted a blog article on Microsoft TechNet called "IT Skills Development: Top 10 Essential IT Skills" which is pretty good.  I don't necessarily agree with his list, even on a purely pragmatic level, but after reading it I got to thinking about a more realistic "Top 10 List" of my own.  However, there is one VERY IMPORTANT aspect that Brian overlooked:  The skills you need are directly associated with [a] the job role you have now, and [b] the job role you are trying to attain.  Because the IT field has become increasingly specialized, the skills are also becoming more specific to each role.  So I'll try to break it down by general roles

PC Technician

1. Master eating spicy foods and consuming lots of beer or Jaegermeister
2. Know your sports teams and league standings
3. Know country or pop / hip-hop music
4. Know at least ten dirty jokes
5. Jeans, Van's shoes, T-shirts that say "There's no place like 127.0.01"

Software Engineer

1. Master your iPod or Zune, etc. (coders rarely talk, they work alone)
2. Learn the latest buzz terms even if you work with 1990's technology
3. Starbucks for breakfast, lunch and maybe dinner
4. Know your alternative musicians and hep TV shows
5. Jeans, flip-flops, T-shirts that say "void main()…"

Systems Engineer / Architect / Analyst

1. Play fantasy football or be fluent about some Pro sports league
2. Put charts and diagrams on every wall (MSDN PDC charts work great)
3. Buy the latest smartphone (DroidX, iPhone4, etc.) and learn enough secret tips to impress your coworkers while you…
4. Go out to lunch almost every day
5. Dockers, Polo shirts, casual dress shoes, sunglasses on top of head even at night.

Department Manager

1. Stock cabinet with Mylanta, Exedrin and Vitamins
2. Learn to appreciate cold coffee (I'm not talking about iced latte's either)
3. Picture frames with family and fishing trips (the kind you'll never go on again)
4. Dying potted plants
5. Dockers, Dress shirts with rolled sleeves and sloppy tie, stained t-shirt underneath

Project Manager

1. Books about PMP trends
2. Framed PMP certs on walls, desk junk also
3. Stacks of useless papers all over the place
4. An inefficient meeting calendar with no time to do anything besides meetings
5. Similar attire to Department Manager on bad days, more like CTO on good days

CTO

1. Sharp dresser, spend a lot on clothing
2. Drive a nice sports car, keep it clean and shiney also
3. Latest smartphone
4. Laugh at all the CIO, and CxO jokes (and know enough semi-dirty jokes for the after-parties)
5. Dockers or Suit.  Hawaiian shirts on Fridays, if you even come in on Fridays

CIO

1. BMW, Lexus, Infinity or Cadillac SUV with golf clubs sticking out the back
2. Picture frames with grandchildren and platoon photos from back in the miliary
3. Sports memorabilia (autographed baseball gloves, footballs, framed photos, etc.)
4. Business Philosophy books on shelves (with plenty of dust on them)
5. Suits, Suits and more Suits

Ok, so these are all 5's, not 10's.  Eh.

Most Vision Statements are Written by Stevie Wonder

If your company vision or mission statement is longer than one sentence: start over!

They should be as brief as a Chinese fortune cookie statement. I'm so tired of all the pompous, circle-jerking verbose crap being shoved into the faces of web site visitors. The stupid and meaningless MBA-babble that amounts to less-than-air. The usual "to persevere to endeavor to meet or exceed the expectations of our valued customers" blah blah blah.

If you're having writer's block, here's some mission statement suggestions:

"To kick ass, make money, and crush the competition"

"To get, and stay rich"

"To keep customers happy"

"Give them what they want"

"Great products. Great service."

You get the idea. Now, get to work.