Sometimes when I've had enough coffee and/or beer, I drift off into thinking some concept "ahead" is it might likely evolve. After reading a few articles about the arcane laws in the U.S. regarding personal use of solar energy, and others on 3D printing, it dawned on me that what we're seeing is the first inch of what will inevitably become a world in which we grow less dependent on the providings of others.
3D printing, for example, will enable us (in time) to create many of the things we have to purchase today. Sure, we'll need to obtain the media from which the printer can generate objects. But that's just for now.
The issue of solar energy for personal use, and the threat it poses to current energy companies like Dominion and Con-Ed sheds light on the concern they have that we (citizens) may not need their services in the future. They are understandably worried, and are therefore busy lobbying our government folks to slow things down until they can figure a way to put a rope around it all, and remain relevant, and more importantly: remain in control of things.
But for now, we buy things made by others. Imported from other places. But someday, we will be able to make a lot of things ourselves, without leaving our homes. As that situation evolves over decades and centuries, imagine where that might lead. Imagine when we can truly make "anything" from some sort of device of our own control. The power balances around the planet of "haves" and "have-nots" will surely shift in other directions. In which directions we can't know at this point, but it will change for sure.
And when we can generate our own power, make our own contraptions, and not have to barter and trade for most things, what then? What do humans do when they don't need other humans by necessity? We will obviously still remain connected for social and personal reasons, but how about the impact that could have on incidental connections, such as getting to know the grocery store clerk, the bartender, the hair cutter, or the school teacher? Even schools, and other places of collective presence may become obsolete, as we are increasingly able to get things like education at home.
Maybe some day, we will have developed the means to literally organize molecules to create anything we desire. Alchemy realized. We are already playing around with moving molecules without touching them (sort of), and moving beyond status quo measures of speed and velocity (link). That means that it could be possible that even travel becomes advanced enough for us not to depend on airlines and passenger trains. Who knows?
The more we evolve technologies, and the more they become increasingly affordable, the more scale this adds to the existing progressive curves of each. The pace is getting faster with each turn. What we once predicted to arrive in ten years, now arrives in five or six. As another decade passes, that window shrinks even more, since the supporting technologies for generating new technologies are also improving. It's like a fire that feeds itself by feeding itself even faster.
Imagine a world where you won't *need* to leave your home to get food, water, or pay anyone else to get electricity, Internet connectivity (or whatever replaces the Internet by then), or to repair things that break around you? Will we let that evolve on its own? Or will we see that coming and collectively work to install guardrails into this evolution so that we remain in "need" of each other to some extent? Who knows.
Right now, you can build your own aircraft, but you must obtain a license and authorization to fly it, with some restrictions and allowances based on who you are, where you are, where you want to fly it, and what kind of aircraft you build. Imagine the positive and negative implications if those restrictions and constraints were removed.
Time for a break. Enjoy your weekend!
Namaste
Showing posts with label thoughts. Show all posts
Showing posts with label thoughts. Show all posts
Sunday, August 17, 2014
Wednesday, June 11, 2014
Asset Inventory 101 - Myths and Realities
This post is the result of trying to explain IT inventory to multiple people, multiple times, and them still not "getting it". Rather than wear myself out, which I will probably still do anyway, I plan on pointing them here to read my thoughts on it, and I can then go back to babbling incoherently to myself. I promised to post a "tech-oriented" article soon, but this is borderline, so nanny-nanny-boo-boo, I'm counting it as tech-oriented.
If you ask me about Inventory, I will ask if you read this article. If you say "no", I will tell you to read this article and walk away, probably while laughing. If you say "yes", I will say "go back and read it again", and laugh even louder.
(noun): A complete list of the things in a place".
(verb): the act or process of making a complete list of the things that are in a place : the act or process of making an inventory". - Merriam-Webster's Dictionary
Go back and read that again. Got it memorized? Okay, let's look at the noun side...
There's also the Manufacturer. Model. Part Number. Serial Number. Contract number(s). Department/Division/Sector/Group/Team/Project names and numbers. And let's not forget the abstracts like category, type, family, class, species, and all that.
The goal of inventory, and inventory tracking efforts is, or should be, to confirm existence, disposition and ownership of assets. The real goal being a financial implication of course. What do you own? Where is it? Who is using it? What is it used for? Who's paying for it? When does it "expire"?
The most common method for gathering and tracking inventory is what is commonly referred to as "input-output differential". Capture what comes in (purchase order, or birth certificate), what goes out (inventory record audit, or death certificate) and finding the gaps. The gaps are where the fun really begins.
What happened to it? Lost? Stolen? Transgender operation? Was it really the property of the organization, or was it loaned to them for temporary use? Was it a demo from a vendor? The list goes on and on.
Just as a Census tries to verify you're still among the living, breathing creatures, who are paying taxes and adding to landfills... so are the aims of products like Microsoft System Center Configuration Manager, Solarwinds, Tivoli, Kaseya, LabTech, and (cough-cough) several products I've developed in the past as well.
So, in addition to what came in the door, and what is known to have departed, there is now a third status of "what's it doing now?" Things that can be poked at to verify where and what an asset is, include Active Directory, network monitoring systems, PING, and so on. An "Asset Manager" job title can often involve a lot of legwork.
Now, think of all the "things" that pertain to labeling YOU as an entity. Your birth certificate. Driver's license. Voter registration. Tax bills. Credit cards. Bank accounts. On and on.
Do any of those things GUARANTEE your existence? No. Do they confirm you are still among the "living" (I'll leave that for you to decide on the definition)? No. They are simply artifacts that help SUPPORT the assertion that you exist.
What is the birth date of a computer? The date it was purchased? The vendor warranty start date? The OS installation date? The technician-installation date? If you base it on the OS install date, and you reinstall the operating system, what happens to the birth date then? Does it fall back to something else?
If you purchase it, and it takes a while to get from the warehouse, to the workbench, to the truck, to the technician to being delivered and setup, which event date are you picking as the "start" or "birth" date of that asset? Have you consulted your Finance folks about this? Your attorneys? You should.
When you record the purchase and deployment of this asset, what then? Do you track it during the rest of its life? Do you track the retirement and disposal of it too? Some places do. Some don't. Some are required by law to track some, or all of this. Which are you required to track?
Even if you are self-employed, talk to an accountant or legal advisor about whether you need to track thigns, and what to track.
Some questions to ask:
From my experiences, most businesses track more than they need to, and ignore things they shouldn't ignore as well.
Definition: Software = "the programs that run on a computer and perform certain functions" - Merriam-Webster's Dictionary
What does that mean? What is a program? Is that Microsoft Word? Is that the Snipping Tool or Narrator feature? Is that .NET Framework 4.5? Is that Java Runtime? Is that a DLL or COM file? Is it a locally stored App-V or ThinApp reference? Is that a shortcut to a MED-V or remote VDI resource (desktop or application)? Is that a URL to a web application? What is it?
What does that mean?
If you query a computer for what software it has installed, where do you begin? Does it all exist in the Control "Add or Remove Programs" list? Usually. But not always. How about crawling through that icky Registry? More stuff, sure, but is it easy to parse and understand? Hmm. How about crawling the good old file system and parsing through EVERY SINGLE FILE that is known to have an executable capability?
The answer is yes.
Configuration Manager, and products similar to it, often dissect a computer from many angles.
This includes files, folders, the Registry, and my personal favorite: WMI. Slithering through the various CIM repository stacks can yield all sorts of juicy bits of data about hardware and software.
But... Is this really what you're after?
So you have a product installed. Now what? Does that constitute a 'license'? What is a license? What kind of license is it? Per-machine? Per-user? Per-CPU? Per-network? Per-domain or site? Per-company? Open Source? What? And what about FlexLM type licensing, where the node doesn't matter as much as the total, concurrent usage limit?
If you have the option to use floating/network licensing for groups of similar products, I always recommend that option if you can afford it.
So, while you can get sloppy about hardware inventory, I would not recommend you take the same light-hearted approach to software inventory. I've seen "settlements" applied that nearly ended a business due to the costs, but thankfully, in none of those situations was I aware or implicated of the neglect prior to the doors getting kicked down. Don't be one of those businesses.
Okay, so that covers a bit of hardware and software.
Simple as multivariate Calculus and molecular bonding, and clear as mud.
Are you starting to drink yet? You will.
Think about that every time you're walking through CostCo, Sam's Club or BJ's and you see a clerk scanning shelves to do "spot check inventory". If there was one system to track and verify all of it, that wouldn't be required.
Every time I sit in a meeting where some vendor comes in to pitch some magical product to report all of their inventory without any outside help, I look at my shoes, smile and think about my next alcoholic beverage, saying to myself "here we go again..."
If you ask me about Inventory, I will ask if you read this article. If you say "no", I will tell you to read this article and walk away, probably while laughing. If you say "yes", I will say "go back and read it again", and laugh even louder.
What is Inventory?
Definition...(noun): A complete list of the things in a place".
(verb): the act or process of making a complete list of the things that are in a place : the act or process of making an inventory". - Merriam-Webster's Dictionary
Go back and read that again. Got it memorized? Okay, let's look at the noun side...
Inventory Science 101
What is "inventory" really? Basically, it's supposed to be about tracking and reporting what you own, or what you have, and where it's located. But there's usually a lot more to it than that. Who's using it. What it's used for. Who bought it. Who pays for it. How it is configured. What it's related to, or associated with.There's also the Manufacturer. Model. Part Number. Serial Number. Contract number(s). Department/Division/Sector/Group/Team/Project names and numbers. And let's not forget the abstracts like category, type, family, class, species, and all that.
The goal of inventory, and inventory tracking efforts is, or should be, to confirm existence, disposition and ownership of assets. The real goal being a financial implication of course. What do you own? Where is it? Who is using it? What is it used for? Who's paying for it? When does it "expire"?
The most common method for gathering and tracking inventory is what is commonly referred to as "input-output differential". Capture what comes in (purchase order, or birth certificate), what goes out (inventory record audit, or death certificate) and finding the gaps. The gaps are where the fun really begins.
What happened to it? Lost? Stolen? Transgender operation? Was it really the property of the organization, or was it loaned to them for temporary use? Was it a demo from a vendor? The list goes on and on.
Just as a Census tries to verify you're still among the living, breathing creatures, who are paying taxes and adding to landfills... so are the aims of products like Microsoft System Center Configuration Manager, Solarwinds, Tivoli, Kaseya, LabTech, and (cough-cough) several products I've developed in the past as well.
So, in addition to what came in the door, and what is known to have departed, there is now a third status of "what's it doing now?" Things that can be poked at to verify where and what an asset is, include Active Directory, network monitoring systems, PING, and so on. An "Asset Manager" job title can often involve a lot of legwork.
What Constitutes "Things" and "Places"?
If we use YOU as a metaphor, then a human being is an inventory asset or item. The place would be (or could be), your home address. It could also be your employer's address, or your car (VIN or license plate).Now, think of all the "things" that pertain to labeling YOU as an entity. Your birth certificate. Driver's license. Voter registration. Tax bills. Credit cards. Bank accounts. On and on.
Do any of those things GUARANTEE your existence? No. Do they confirm you are still among the "living" (I'll leave that for you to decide on the definition)? No. They are simply artifacts that help SUPPORT the assertion that you exist.
Metaphorically Speaking: Computers
Now that we've strolled off into metaphor-land, let's bring it back to the meat-and-potatoes: Computer assets. Desktops, laptops, tablets, smartphones, appliances, routers, hubs, switches, printers, power supplies, storage units, MODEM's, peripherals of all kinds, you name it.What is the birth date of a computer? The date it was purchased? The vendor warranty start date? The OS installation date? The technician-installation date? If you base it on the OS install date, and you reinstall the operating system, what happens to the birth date then? Does it fall back to something else?
If you purchase it, and it takes a while to get from the warehouse, to the workbench, to the truck, to the technician to being delivered and setup, which event date are you picking as the "start" or "birth" date of that asset? Have you consulted your Finance folks about this? Your attorneys? You should.
When you record the purchase and deployment of this asset, what then? Do you track it during the rest of its life? Do you track the retirement and disposal of it too? Some places do. Some don't. Some are required by law to track some, or all of this. Which are you required to track?
Just because you "Can", does that mean you "Should"?
If you are an IT person working for someone else (i.e. not self-employed), and you haven't sat down (or consulted with) someone in a legal and/or financial role in your organization, I strongly recommend you do so before embarking on any effort to track and report inventory of any kind. I cannot stress that enough.Even if you are self-employed, talk to an accountant or legal advisor about whether you need to track thigns, and what to track.
Some questions to ask:
- What are the tax implications?
- What are the support contract and cost implications?
- What are the regulatory compliance implications?
- What are the IT support implications?
From my experiences, most businesses track more than they need to, and ignore things they shouldn't ignore as well.
Ah, Yes: Software
Just when the folks feel good about their grasp of tangible hardware inventory, we open the gates and let the starving lions and alligators into the arena: software licensing.Definition: Software = "the programs that run on a computer and perform certain functions" - Merriam-Webster's Dictionary
What does that mean? What is a program? Is that Microsoft Word? Is that the Snipping Tool or Narrator feature? Is that .NET Framework 4.5? Is that Java Runtime? Is that a DLL or COM file? Is it a locally stored App-V or ThinApp reference? Is that a shortcut to a MED-V or remote VDI resource (desktop or application)? Is that a URL to a web application? What is it?
What does that mean?
If you query a computer for what software it has installed, where do you begin? Does it all exist in the Control "Add or Remove Programs" list? Usually. But not always. How about crawling through that icky Registry? More stuff, sure, but is it easy to parse and understand? Hmm. How about crawling the good old file system and parsing through EVERY SINGLE FILE that is known to have an executable capability?
The answer is yes.
Configuration Manager, and products similar to it, often dissect a computer from many angles.
This includes files, folders, the Registry, and my personal favorite: WMI. Slithering through the various CIM repository stacks can yield all sorts of juicy bits of data about hardware and software.
But... Is this really what you're after?
So you have a product installed. Now what? Does that constitute a 'license'? What is a license? What kind of license is it? Per-machine? Per-user? Per-CPU? Per-network? Per-domain or site? Per-company? Open Source? What? And what about FlexLM type licensing, where the node doesn't matter as much as the total, concurrent usage limit?
If you have the option to use floating/network licensing for groups of similar products, I always recommend that option if you can afford it.
Software Licensing Audits
If you've ever witnessed a license audit from an external investigation, it's not fun. They tend to come in one of two flavors: Vendor and BSA. If the vendor audits you, that's good. They want to keep your business, so they will try to negotiate terms to help avoid losing your business, if possible. If the BSA, or another third-party entity, comes knocking, swallow whatever pills you have left and take a deep breath. It may very well be an unpleasant experience, as they are paid by levied penalties and have no need to retain your business.So, while you can get sloppy about hardware inventory, I would not recommend you take the same light-hearted approach to software inventory. I've seen "settlements" applied that nearly ended a business due to the costs, but thankfully, in none of those situations was I aware or implicated of the neglect prior to the doors getting kicked down. Don't be one of those businesses.
Okay, so that covers a bit of hardware and software.
Simple as multivariate Calculus and molecular bonding, and clear as mud.
Are you starting to drink yet? You will.
Summary
If anyone says there is, or should be, "one inventory source" to answer all of these questions, they are brain damaged or stupid. The desire is noble. The reality is clear: a singular source of "authoritative" inventory data is impossible. It has to be derived and reconciled from multiple angles.Think about that every time you're walking through CostCo, Sam's Club or BJ's and you see a clerk scanning shelves to do "spot check inventory". If there was one system to track and verify all of it, that wouldn't be required.
Every time I sit in a meeting where some vendor comes in to pitch some magical product to report all of their inventory without any outside help, I look at my shoes, smile and think about my next alcoholic beverage, saying to myself "here we go again..."
Thursday, June 5, 2014
Dave's ill-informed, under-educated, dumbass "Top 5" Rules for IT operational success
Dave's ill-informed, under-educated, dumbass "Top 5" Rules for IT operational success.
1. Clear Direction
Can you state the reason, rationale and impact of any task or project in ONE SENTENCE?
Yes - Proceed
No - You are doomed to horrific failure
2. Chain of Command
Do you receive ALL of your tasking from your direct line manager?
Yes - Proceed
No - You are doomed to horrific gang-raping failure
3. Personal Cohesion
Do the people in your group, team, or project get along well on a personal and personality level?
Yes - Proceed
No - You might succeed, but you will eventually fail in a horrific way
4. Personal Interest
Is it fairly normal for the people on your teams to work additional hours because they LIKE doing what they do, as opposed to doing it in order to avoid getting reamed in the next status meeting for falling behind?
Yes - Proceed
No - You are doomed to tragic, catastrophic failures of Biblical proportions.
5. Vendor Agnosticism
Do most of the decisions regarding strategic operations (hardware, software, internal and external services, staffing, etc.) tend to be knee-jerk towards one vendor per category, or are they up for grabs during each review?
Yes - There is hope for your organization
No - Forget it and start putting in applications at another place as soon as possible
1. Clear Direction
Can you state the reason, rationale and impact of any task or project in ONE SENTENCE?
Yes - Proceed
No - You are doomed to horrific failure
2. Chain of Command
Do you receive ALL of your tasking from your direct line manager?
Yes - Proceed
No - You are doomed to horrific gang-raping failure
3. Personal Cohesion
Do the people in your group, team, or project get along well on a personal and personality level?
Yes - Proceed
No - You might succeed, but you will eventually fail in a horrific way
4. Personal Interest
Is it fairly normal for the people on your teams to work additional hours because they LIKE doing what they do, as opposed to doing it in order to avoid getting reamed in the next status meeting for falling behind?
Yes - Proceed
No - You are doomed to tragic, catastrophic failures of Biblical proportions.
5. Vendor Agnosticism
Do most of the decisions regarding strategic operations (hardware, software, internal and external services, staffing, etc.) tend to be knee-jerk towards one vendor per category, or are they up for grabs during each review?
Yes - There is hope for your organization
No - Forget it and start putting in applications at another place as soon as possible
Sunday, April 20, 2014
IT Catastrophes: Triage and Compression with Fries and Coke
Triage (noun)
(b) the sorting of patients (as in an emergency room) according to the urgency of their need for care
(b) the sorting of patients (as in an emergency room) according to the urgency of their need for care
Compression ()
The state of being compressed (re: reduced in size or volume, as by pressure)
(source: Merriam-Webster online dictionary)
What I'm talking about is a loose comparison and contrast with these two words as they relate to medical and technology fields. It is however a very real subject (or subjects) for those of us who occasionally deal with critical outages, especially those which involve things like:
- Highly-Available Hosting Services (think: Google, Microsoft, Facebook, etc.)
- Mission Critical Systems (think: Defense, Lifesaving, etc.)
- Service Level Agreements (the dreaded SLA's)
It's kind of funny how most businesses feel their operations are "mission critical" or "highly-available", when they're being subjective. From an objective view however, it's not always as "critical" when things go "down" for a few minutes; even a few hours.
By the way: Compression, as it pertains to this article relates to the compression of time in which you have to operate in. The time between a failure and sufficient restoration of services.
When dealing with a system outage in a truly "critical" environment, the first steps are pretty much the same as what an Emergency Medical Technician (EMT) would have to consider:
- What exactly is not working?
- How serious is the impact?
- What is known about what led to this outage?
- How long has it been down?
- How much time is left?
You were probably thinking of the Who, What, Where, When, Why and How sequence. I kind of tripped you up with two What's and three How's. (Technically, #4 could be a "when", and #2 could be a "who" or "where", but whatever). Let's move along.
With regards to a human, the general rule of thumb is 4-6 minutes, total. That's about how long the brain go without Oxygen and still recover. Compression CPR is usually the first course of action to sustain blood flow; keeping the remaining oxygen-rich blood reserves moving through the brain. Enough pseudo-medical blabbering. The main point is that there is a "first-course of action" to resort to in most cases.
What aspects are shared between a medical outage and an IT system outage?
- There are measurable limits to assessing what can be saved and how
- There are identifiable considerations with regards to impact on various courses of action
- Techniques can be developed and stored for more efficient use when needed
- Steps can be taken to identify probable risks and applying risk mitigation
With regards to a system-wide outage, the general rule of thumb is not so clear-cut as the 4-6 minute rule. It truly varies by what the systems does and who (or what) it supports. Consider the two following scenarios:
Scenario 1
The interplanetary Asteroid tracking system you maintain is monitoring a projectile traveling at an extremely high velocity towards planet Earth. The system "goes down" during a window of time in which it would be able to assess a specific degree of variation of its trajectory. The possible margin of error from the last known projected path could have it hit the Earth, or miss it by a few hundred miles. The sooner the system is back on line, the sooner a more precise forecast can be derived.
Every hour the system is offline, the margin of error could potentially be re-factored (and reduced) by a considerable amount, possibly ruling out a direct hit. The best estimate of a direct impact places the date and time somewhere around one year from right now. Your advisers state that it would require at least six months to prepare and launch an interceptor vehicle in time to deflect or divert the projectile away from a direct Earth impact.
Scenario 2
Your order-tracking system for MySuckyShoes.com is down and customers are unable to place orders for new sucky shoes. Your financial manager estimates that during this particular period of the year, using past projections, combined with figures collected up until the outage, every hour the system is offline, you are losing $500,000 of potential sales revenue. The system has reportedly been offline for two hours. So far, that's $1 million bucks.
Which of these scenarios is more critical?
Answer: It depends
What are the takeaways from each scenario?
- How long do you have to restore operations before things get really bad?
- Having the time window defined, what options can you consider to diagnose and restore services?
- How prepared are you with regards to the outage at hand?
- What resources are at your disposal, for how long, and how soon?
In the first scenario, you have roughly six months to get things going. Odds would be generally good to assume you can restore services sooner than that, but what if the outage was caused by an Earthquake that decimated your entire main data center? Ouch.
In the second scenario, the margin would depend on the objective scale of revenue your business could withstand losing. If you're Google, a million dollar outage might be bad, but not catastrophic. If you're a much smaller business, it could wipe you out entirely.
What's really most important (besides the questions about what systems are down, why, when and how) is knowing what the "limits" are. Remember the 4-6 minutes rule? SLAs are obviously important, but an SLA is like a life insurance policy; not like a record of discussion between the EMT in the ambulance with the attending physician back at the hospital ER. One is prescriptive and didactic. The other is matter-of-fact, holy shit, no time to f*** around.
QUESTION: When was the last time you or your organization sat down and clearly defined what losses it can absorb and where the line exists whereby you would have to consider filing for bankruptcy?
Is your IT infrastructure REALLY critical to the business, or just really important? In other words: could your business continue to operate at ANY level without the system in operation?
Forget all the confidence you have in your DR capabilities for just a minute. Imagine if ALL of your incredibly awesome risk avoidance preparation were to fail. How long could you last as a business? At what point would you lose your job? At what point would your department, division or unit fail? At what point would the organization fail? Or do you think it's fail-proof?
Tuesday, March 25, 2014
Factors of Refactoring
Even if you've never written a line of program or script code in your life, you know what refactoring is. You may not have known it, but you knew it. Confused yet? Let me help.
Refactoring is basically "refinement" or "optimization" or "streamlining".
Let's try this analogy on:
You build a book case from scraps of wood and some hand tools in your garage. After the first shelf, you decide you want to build another one. But this time you modify the design to change some of the parts and how they're joined together. Maybe you change it so there are fewer parts overall. The first one was assembled from eight (8) pieces of wood, and sixty-four (64) screws. The second one from six (6) pieces, and thirty-two (32) screws. After a few more, you realize you can rearrange the cut patterns on a sheet of raw plywood to get more parts from each sheet with less wasted scraps. Eventually, you have a sturdier product, requiring less material and lower cost to build each one.
Or how about this:
You cook meals and find that you tend to make mostly Italian recipes. After several dinners you realize that by reorganizing the pantry and spice rack you can more easily get the ingredients to the stove top in less time and with less confusion. As time goes on, you move things around: pot racks, islands, roller carts, etc. After a month of "trial and error" you now have the most streamlined kitchen setup imaginable. Everything from the cookware, cooking area and ingredients to the paths you traverse moving from one station to another is now as good as it can be. Eventually, you realize you've reduced the time and effort required to cook most meals by 50% and lowered your costs as well.
Or how about this:
You wrote a script, and it does a lot of separate, but sequentially-dependent tasks in order to arrive at a desired result. The first draft contains 12 distinct custom function blocks, and repeated "for" or "while" loops on the same of data. The second draft contains 10 distinct custom function blocks and the repeated iteration blocks are now calls to one of the custom functions. By the third draft, the total number of code lines has been reduced from 1034 to 811 and down to 643.
Going back to look for ways to accomplish the same task in fewer steps. With better quality results. Improved reliability, predictability, dependability. All those other -ilities. Reusing things instead of making new ones all the time. Getting more out of same effort than you did before.
This is refactoring.
Case in Point: Program Files Example 101
Phase 1 - two files, one does option "A" and the other option "B"
Phase 2 - files are combined and use input parameter (i.e. "switches") to drive the code workflow.
Phase 3 - instead of distinct blocks of code, sections are combined into calls to one function with input params.
Phase 4 - instead of forked code paths in each function, the function now passes the input params through to drive external interfaces via concatenated references (e.g. you call one SQL view or another by passing in the param as the view name itself)
Phase 5 - SQL view is replaced with a stored procedure or db function that builds expression with input param directly.
Phase 6 - your work day now goes from 6 hours of keyboard banging and eating at your desk, to 4 hours of enjoyable keystrokes and going out for lunch.
For those of you who already knew this and are staring at this page like you're witnessing a cat eating a pig, whole, I apologize for your agony.
Refactoring is basically "refinement" or "optimization" or "streamlining".
Let's try this analogy on:
You build a book case from scraps of wood and some hand tools in your garage. After the first shelf, you decide you want to build another one. But this time you modify the design to change some of the parts and how they're joined together. Maybe you change it so there are fewer parts overall. The first one was assembled from eight (8) pieces of wood, and sixty-four (64) screws. The second one from six (6) pieces, and thirty-two (32) screws. After a few more, you realize you can rearrange the cut patterns on a sheet of raw plywood to get more parts from each sheet with less wasted scraps. Eventually, you have a sturdier product, requiring less material and lower cost to build each one.
Or how about this:
You cook meals and find that you tend to make mostly Italian recipes. After several dinners you realize that by reorganizing the pantry and spice rack you can more easily get the ingredients to the stove top in less time and with less confusion. As time goes on, you move things around: pot racks, islands, roller carts, etc. After a month of "trial and error" you now have the most streamlined kitchen setup imaginable. Everything from the cookware, cooking area and ingredients to the paths you traverse moving from one station to another is now as good as it can be. Eventually, you realize you've reduced the time and effort required to cook most meals by 50% and lowered your costs as well.
Or how about this:
You wrote a script, and it does a lot of separate, but sequentially-dependent tasks in order to arrive at a desired result. The first draft contains 12 distinct custom function blocks, and repeated "for" or "while" loops on the same of data. The second draft contains 10 distinct custom function blocks and the repeated iteration blocks are now calls to one of the custom functions. By the third draft, the total number of code lines has been reduced from 1034 to 811 and down to 643.
Going back to look for ways to accomplish the same task in fewer steps. With better quality results. Improved reliability, predictability, dependability. All those other -ilities. Reusing things instead of making new ones all the time. Getting more out of same effort than you did before.
This is refactoring.
Case in Point: Program Files Example 101
Phase 1 - two files, one does option "A" and the other option "B"
Phase 2 - files are combined and use input parameter (i.e. "switches") to drive the code workflow.
Phase 3 - instead of distinct blocks of code, sections are combined into calls to one function with input params.
Phase 4 - instead of forked code paths in each function, the function now passes the input params through to drive external interfaces via concatenated references (e.g. you call one SQL view or another by passing in the param as the view name itself)
Phase 5 - SQL view is replaced with a stored procedure or db function that builds expression with input param directly.
Phase 6 - your work day now goes from 6 hours of keyboard banging and eating at your desk, to 4 hours of enjoyable keystrokes and going out for lunch.
For those of you who already knew this and are staring at this page like you're witnessing a cat eating a pig, whole, I apologize for your agony.
Thursday, March 13, 2014
NIH
This may be a bit deep, but I just finished folding laundry at a nearby laundromat whilst a group of over-caffeinated high-schoolers pretended it was audition night for "The Voice" and "Tosh.O" in the same place. After getting home and putting the goods away, I did dishes and consumed a tasty Dogfish Burton Baton and now my brain needs some playtime. You've been warned. Sit down. Strap in. Enjoy the ride....
To many folks, the term "NIH" means National Institutes of Health. But to many folks in the legal field, particularly those specializing in intellectual property issues ("IP" law, that is), it means "not invented here". It's a uniquely-American term, but the concept predates America itself actually. Allow me to digress...
I learned this while doing some contract work in that field a few years back; patent drawings and technical procedure writing actually. "NIH" refers to a policy some renown international corporate entities (I won't name any) have towards how they approach dealing with intellectual property. This encompasses copyright, patents and trademarks, obviously, but it also includes service marks and more.
In basic English: If the item was "not invented here" they don't want anything to do with it. In most cases, they mean "at all", as in "not in any respect whatsoever". For example, if you invent some cool toy, and approached some particularly HUGE toy manufacturing corporation to negotiate some kind of "deal" (I'll leave their actual name to your imagination), and they adhere to the NIH policy, and you are not a direct-employee of that company, they will very likely ask you to leave. If you continue to insist on a discussion, they may call security to help you find the door.
I am not joking.
So, during a recent discussion I had with some colleagues (past and present) about the subject of "why do so many IT organizations seem to abhor the idea of their own staff daring to develop their own tools for their own needs and then being so brazen as to ask their employers if they'd like to join in on the party?" Keep in mind that this is not about selling the invention to the employer. It's about asking the employer to put some elbow grease into it and help launch the airplane off the flight deck with a little more "umpf!". Of the six or so folks present, and their recollection of some two dozen secondary contacts and colleagues, not ONE of them could recall ever hearing of a successful effort in that regard.
Not one.
I am very familiar with this, as I have been, without planning or expectation, in the center of such situations, many times. At my last four employers in fact. I was present during the putting-out of some particular fires (metaphorically-speaking), in which there were NO available "off-the-shelf" solutions to be had. None. So we built our own (or I built my own). Like many contraptions, mechanical or otherwise, which are conceived to solve a "real" problem, they tend to gain a life of their own. Problems, it seems, tend to recur so having a tool which is custom-fit to solve it tends to be very appealing. Especially when that tool or solution was provided at no "additional" cost to the parties involved.
Yes. No additional cost. Translation: It was conceived, built, tested and applied using existing funding and task vehicles (that's beancounter speak for "it was part of my job duties, so I did it"). Even the technologies involved with building the tool were 100% "free". Things like built-in API's, and SQL Server Express, IIS, scripting, etc. Aside from the already-paid cost of the operating system license itself, there were no additional costs required or incurred.
So, why the fuss?
That's a good question. A lot of theories were discussed around this one key aspect. Everything from businesses shying away from stepping outside of their "core competencies" to "perceived risk" to "obligatory support liabilities" and so on. Blah blah blah. Fear. It's just fear. I add laziness to that, but fear and laziness go together like hookers and politicians.
Then it dawned on me that it's really about NIH. I realize that fear+laziness nearly equates to NIH in most respects, but it has a different sauce poured over it.
What's even more interesting about this entire mess is that in none of the examples we could cite were there any alterior motives on the part of the employee/developer. It was all above-board and in good faith, in which they not only accomplished the item in question, but in how they approached and engaged their employer. The employer however, no matter how the approach was toasted, garnished and served-up, consistently took a hostile, defensive stance in regards to their reaction to the employee. As if indicating their distrust in the employee; probably assuming the employee concocted the whole idea just to negotiate a deal in the same sense as a blackmail operation. Holding them hostage. Whatever that could mean.
But the question remains: why? Why not actually hold detailed, sincere discussions with the employee, rather than closing the gates and shooting arrows off the guard towers?
Legal risk. Once again, attorneys, and their corporate financial overlords (retainer clients, usually) have successfully cultivated an atmosphere of risk-avoidance. Risk avoidance is another name for "fear of innovation". Imagine if Henry Ford were told that challenging horses would land him in court? I'm sure someone tried it, but what if he actually caved in to that? Oh boy. You can argue that the environment would have fared better today than it has already, but think of the wider ramifications of that. Now, start that idea-clock in motion today and imaging where it will be in 50 or 100 years.
It's already too late to save our federal government system from the corruption of corporate PAC influences. Let's not let the rest of the baby go down the bathtub drain as well. There's a few companies and entrepreneurs out there still taking risks (Elon Musk, Richard Branson being just two of them), so maybe there's still hope things will turn around in favor of imagination and risk-taking. It can only work when it's cooked in the same pot as the money comes from though. It seems those of us stirring around in the bottom ranks of the IT world are going to have to fight our way out day by day, in spite of the risk-averse surroundings.
But I digress. Sweet dreams! :)
To many folks, the term "NIH" means National Institutes of Health. But to many folks in the legal field, particularly those specializing in intellectual property issues ("IP" law, that is), it means "not invented here". It's a uniquely-American term, but the concept predates America itself actually. Allow me to digress...
I learned this while doing some contract work in that field a few years back; patent drawings and technical procedure writing actually. "NIH" refers to a policy some renown international corporate entities (I won't name any) have towards how they approach dealing with intellectual property. This encompasses copyright, patents and trademarks, obviously, but it also includes service marks and more.
In basic English: If the item was "not invented here" they don't want anything to do with it. In most cases, they mean "at all", as in "not in any respect whatsoever". For example, if you invent some cool toy, and approached some particularly HUGE toy manufacturing corporation to negotiate some kind of "deal" (I'll leave their actual name to your imagination), and they adhere to the NIH policy, and you are not a direct-employee of that company, they will very likely ask you to leave. If you continue to insist on a discussion, they may call security to help you find the door.
I am not joking.
So, during a recent discussion I had with some colleagues (past and present) about the subject of "why do so many IT organizations seem to abhor the idea of their own staff daring to develop their own tools for their own needs and then being so brazen as to ask their employers if they'd like to join in on the party?" Keep in mind that this is not about selling the invention to the employer. It's about asking the employer to put some elbow grease into it and help launch the airplane off the flight deck with a little more "umpf!". Of the six or so folks present, and their recollection of some two dozen secondary contacts and colleagues, not ONE of them could recall ever hearing of a successful effort in that regard.
Not one.
I am very familiar with this, as I have been, without planning or expectation, in the center of such situations, many times. At my last four employers in fact. I was present during the putting-out of some particular fires (metaphorically-speaking), in which there were NO available "off-the-shelf" solutions to be had. None. So we built our own (or I built my own). Like many contraptions, mechanical or otherwise, which are conceived to solve a "real" problem, they tend to gain a life of their own. Problems, it seems, tend to recur so having a tool which is custom-fit to solve it tends to be very appealing. Especially when that tool or solution was provided at no "additional" cost to the parties involved.
Yes. No additional cost. Translation: It was conceived, built, tested and applied using existing funding and task vehicles (that's beancounter speak for "it was part of my job duties, so I did it"). Even the technologies involved with building the tool were 100% "free". Things like built-in API's, and SQL Server Express, IIS, scripting, etc. Aside from the already-paid cost of the operating system license itself, there were no additional costs required or incurred.
So, why the fuss?
That's a good question. A lot of theories were discussed around this one key aspect. Everything from businesses shying away from stepping outside of their "core competencies" to "perceived risk" to "obligatory support liabilities" and so on. Blah blah blah. Fear. It's just fear. I add laziness to that, but fear and laziness go together like hookers and politicians.
Then it dawned on me that it's really about NIH. I realize that fear+laziness nearly equates to NIH in most respects, but it has a different sauce poured over it.
What's even more interesting about this entire mess is that in none of the examples we could cite were there any alterior motives on the part of the employee/developer. It was all above-board and in good faith, in which they not only accomplished the item in question, but in how they approached and engaged their employer. The employer however, no matter how the approach was toasted, garnished and served-up, consistently took a hostile, defensive stance in regards to their reaction to the employee. As if indicating their distrust in the employee; probably assuming the employee concocted the whole idea just to negotiate a deal in the same sense as a blackmail operation. Holding them hostage. Whatever that could mean.
But the question remains: why? Why not actually hold detailed, sincere discussions with the employee, rather than closing the gates and shooting arrows off the guard towers?
Legal risk. Once again, attorneys, and their corporate financial overlords (retainer clients, usually) have successfully cultivated an atmosphere of risk-avoidance. Risk avoidance is another name for "fear of innovation". Imagine if Henry Ford were told that challenging horses would land him in court? I'm sure someone tried it, but what if he actually caved in to that? Oh boy. You can argue that the environment would have fared better today than it has already, but think of the wider ramifications of that. Now, start that idea-clock in motion today and imaging where it will be in 50 or 100 years.
It's already too late to save our federal government system from the corruption of corporate PAC influences. Let's not let the rest of the baby go down the bathtub drain as well. There's a few companies and entrepreneurs out there still taking risks (Elon Musk, Richard Branson being just two of them), so maybe there's still hope things will turn around in favor of imagination and risk-taking. It can only work when it's cooked in the same pot as the money comes from though. It seems those of us stirring around in the bottom ranks of the IT world are going to have to fight our way out day by day, in spite of the risk-averse surroundings.
But I digress. Sweet dreams! :)
Tuesday, February 11, 2014
Plugging Your VBScript Brain into PowerShell
It started with diapers and bottles of milk and soft food. Then cereal and TV dinners in frotn of a real TV. Then it was on to C, then C++, then I moved into LISP and Scheme, and AutoLISP and Visual Basic. Then T-SQL and Batch/Cmd scripting. Then coffee, and on to Javascript and KiXtart and Perl, and after mor coffee: VBscript. And after the coffee ran out, it was beer and then PowerShell. Quick tips, based on my self-conversion efforts thus far:
- Start naming your Sub and Function items using PowerShell syntax, but keeping in mind to glue the Noun/Verb scheme using an underscore ("_"), since you cannot use a hyphen for such things in VBScript. Example:
Function ComputerModel()
...
End Function
...renamed...
Function Get_ComputerModel()
...
End Function - Use consistent commenting throughout your code. If you do that, you can more-easily "port" your code between languages (any language, actually). It also allows for automated self-documentation. While that may seem like an impressive phrase to toss around at parties (it is, by the say, haw haw, cough cough...) when you starting stacking up code into more complex "solutions", it will pay off handsomely when the suits come knocking for professional-looking docs.
- Eat. Drink. Sleep. Find a reason to laugh.
Wednesday, February 5, 2014
BPA. Again? Yes. and THIS time with Fries and a Drink
The Challenge
Your tech staff wants to be able to swap-out existing desktop computers with the least amount of administrative overhead. Basically, they want to be able to walk up with a new computer, unplug the old one, plug in the new one, turn it on and walk away. The stuff on the existing computer should magically end up on the new computer (sans all the usual personal crap that shouldn't be stored on a local computer in the first place).
What are these "stuff"? Applications, default/initial configuration settings, printer mappings, Outlook profile settings, etc.
The Tools at Hand
Active Directory (Windows Server 2012), Group Policy, System Center Configuration Manager (2007, but that's for another discussion), SCCM OSD+MDT+ADK+Coffee, SQL Server 2012, ASP (yes, the sticky, smelly old classic kind), Packaged Software (already loaded into SCCM), a tablet running Windows 8.1 and a bluetooth barcode scanner. Also, a van, a hand-truck, appropriate weather-oriented clothing, hydration substances and a fully-loaded firearm (okay, not for all situations).
Options
Options are good. This is just one option. One that I am fortunate to be working with actually.
If the computer is mapped into the appropriate collections within Configuration Manager, and managed and monitored via logical memberships and dispositional relationships (Active Directory Security Groups, Active Directory Organizational Unit location), you're in what NFL fans would call "the Red Zone".
The Binding Adhesives:
Your tech staff wants to be able to swap-out existing desktop computers with the least amount of administrative overhead. Basically, they want to be able to walk up with a new computer, unplug the old one, plug in the new one, turn it on and walk away. The stuff on the existing computer should magically end up on the new computer (sans all the usual personal crap that shouldn't be stored on a local computer in the first place).
What are these "stuff"? Applications, default/initial configuration settings, printer mappings, Outlook profile settings, etc.
The Tools at Hand
Active Directory (Windows Server 2012), Group Policy, System Center Configuration Manager (2007, but that's for another discussion), SCCM OSD+MDT+ADK+Coffee, SQL Server 2012, ASP (yes, the sticky, smelly old classic kind), Packaged Software (already loaded into SCCM), a tablet running Windows 8.1 and a bluetooth barcode scanner. Also, a van, a hand-truck, appropriate weather-oriented clothing, hydration substances and a fully-loaded firearm (okay, not for all situations).
Options
Options are good. This is just one option. One that I am fortunate to be working with actually.
If the computer is mapped into the appropriate collections within Configuration Manager, and managed and monitored via logical memberships and dispositional relationships (Active Directory Security Groups, Active Directory Organizational Unit location), you're in what NFL fans would call "the Red Zone".
The Binding Adhesives:
- Assuming that the existing computer finds its way into a functional or organizational related Collection within SCCM, you have a means for aiming things at it by function and/or organization (sector, department, division, business unit, etc.)
- Assuming that the existing computer has things configured via Group Policy, it is likely grouped under a logical OU environment.
- Assuming it is targeted via either query-based Collections (handy), or direct-membership Collections (a little more work but still handy) you have another means for aiming things at it in a logical manner.
- Assuming, and this is a reach for some environments, but very common in others: you have barcode labels on assets that are relational to their AD account names, oooh. You are in very good position to throw a touchdown now.
The Process Walk-Through
- Technician arrives at customer location with new computer, already imaged with a generic, standard "load" (Windows, Office, base applications, etc.) and joined to AD in a generic OU. It also has a functional SCCM client agent.
- The technician gets the existing barcode and the new barcode values. Enters them into a web form (from the computer itself or from a third device, such as a tablet or phone). Hit "submit". Swap-out the hardware, reconnect, power up the new stuff and run off with the old stuff.
In the background:
- The data is queued (in a relational database, such as SQL Server) for the "old" and "new" computer names. Since both already exist in AD and in Configuration Manager...
- A scheduled, or triggered, task invokes a script that queries the database for pending items (those which have not been swapped out yet)
- Step 1 is fetching the "old" computer information:
- AD OU
- AD Security Groups
- AD account description property (if desired)
- AD account location property (if desired)
- SCCM direct-membership Collections
- Step 2 is taking action:
- Move "new" computer into correct OU
- Add "new" computer to same AD groups
- Add "new" computer to same SCCM direct-membership Collections
- Update AD account properties (description, location, etc. if desired)
- Disable "old" computer AD account
- Remove "old' computer from AD security groups
- Move "old" computer AD account to special OU (for GPO management aspects)
- Update asset inventory tracking database (operational status, if relevant, etc.)
- Force a restart of the "new" computer (to force GPO updates, SCCM client policy polling and discovery updates)
- Step 3 - mopping up
- No process model is without exceptions: manual installations, special device installation, white-glove stuff, etc.
Suiting Up
All of this is not only possible, it's not that difficult with the right planning and testing. I'm currently using ASP on IIS from an internal Windows Server 2012 box. The queue is managed in SQL Server 2012. The script process uses VBscript, but will soon be ported to PowerShell. The interfaces are COM, WMI, SWBEM, ADO and LDAP/ADSI. All are very common building blocks in Windows environments.
When was the last time you played with a Lego kit or one of those car/ship/aircraft model kits?
Repeat after me: "It often comes with headaches, but I usually love what I do for a living."
:)
Miscellaneous Nerd Notes after a Busy Day at Work
These are just reminders. Today was a rocky start and a smooth ending. Assisted by a relaxing conversation with a long-time colleague (and all-around nice guy), followed by a run around the neighborhood and a cold Belgian Ale to cool down. Some of these may seem obvious to some of you, but they are just reminders for my own feeble brain cells.
The "RuleSet" property for the Configuration Manager SWBEM Collection direct-rule interface property expects a client "name", not a ResourceID.
Make sure your functions return values properly.
There is no such thing as too much error checking.
Remoting is good. Whether it's PowerShell, Sysinternals, or throwing a heavy object at the butthead in the next cube.
Colleagues that consistently shout out "___ is broken." without providing the usual, necessary, and requisite details about "what", "where" and "when", deserve a good choking.
The Office 2013 default UI is pretty, but too cluttered and poorly organized.
The downloads for SQL Server Express 2012 and SSMS for x64 are stupidly confusing and not linked very well on the MS downloads site.
As soon as a social app says it's going to "monetize" it usually means it smells fear from their own staff.
When it snows in Virginia, drivers turn the asshole knob to "max".
Web apps rock. Building them is fun. Using them is rewarding, especially when you build them to solve real problems you face every day.
Listen to the entire problem before responding. Ask questions before spewing directions.
Cats can't eat as much chicken as they think they can. The results usually end up on the floor in the early morning.
The "RuleSet" property for the Configuration Manager SWBEM Collection direct-rule interface property expects a client "name", not a ResourceID.
Make sure your functions return values properly.
There is no such thing as too much error checking.
Remoting is good. Whether it's PowerShell, Sysinternals, or throwing a heavy object at the butthead in the next cube.
Colleagues that consistently shout out "___ is broken." without providing the usual, necessary, and requisite details about "what", "where" and "when", deserve a good choking.
The Office 2013 default UI is pretty, but too cluttered and poorly organized.
The downloads for SQL Server Express 2012 and SSMS for x64 are stupidly confusing and not linked very well on the MS downloads site.
As soon as a social app says it's going to "monetize" it usually means it smells fear from their own staff.
When it snows in Virginia, drivers turn the asshole knob to "max".
Web apps rock. Building them is fun. Using them is rewarding, especially when you build them to solve real problems you face every day.
Listen to the entire problem before responding. Ask questions before spewing directions.
Cats can't eat as much chicken as they think they can. The results usually end up on the floor in the early morning.
Thursday, January 30, 2014
These are a Few of My Favorite Things
Disclaimer: I am not a man of means. I am a man of modest resources, thus I whittle my bucket list to the bare bone. These are but a few of my favorite luxuries in this life. They are not listed in any order.
- My wife, Kathy
- My kids: Rachel ,Sarah, Gabrielle, Zachary
- Timberland black hiking boots
- Subaru AWD cars (I have a 1995 Legacy ESi Wagon with 180,000 miles on it. It still kicks ass)
- Malbec wines (especially from Argentina)
- Belgian Strong Ales (most brands will do just fine)
- TextPad
- Stephen Hawking
- Frank Zappa
- LISP
- Jesus, Buddha, Muhammed, and Abraham
- Life cereal
- Cold, Fresh Water
- A conversation with someone in their 80's or 90's
- Indian Food
- Para-Sailing
- Cross-city Bicycling (fat, trail-tire type, not the sissy skinny tire stuff)
- Oscar Schindler
- Anjeze Gonxhe Bojaxhu
- Tosh.O
- Stephen Colbert
- John Stewart
- Dave Chappelle
- Srirachi Sauce
- U2
- A bonfire with my kids
- Italian Food
- Laughter
Remember: Humor and laughter are the back-scratching of God.
Tuesday, December 3, 2013
Government = Bad. Right?
I was thinking about Dave Chappelle's discussion about "dressing the part", and how it relates to other parts of American society. Maybe you recall his skit about "just because you're dressed like a ___, doesn't make you a ___."? Yeah. That one. This may seem very loosely interpreted, but if you think deep enough (or do enough drugs) it might materialize for you.
When people (okay, Americans mostly) draw up "rules" based on limited experiences, they're tossing out babies and bathwater into the wood-chipper at the same time. After all, when you share a comic that implies "government = evil" you're lumping all of it in one bucket of badness.
Here's a thought: Next time your nearby elementary school is attacked by some nut-job who decides to suit-up and shoot at bystanders, how about you not call the police. Call some private firm and negotiate the rate over the phone and have them come out and take care of it instead. Better yet, forget public schools. Make everyone pay for a private school. Same for libraries, recreation centers, parks, water services, trash pick-up, traffic management, emergency medical services, fire department, whatever. Why stop there? Privatize the entire military, FAA, DOD, FEMA, CDC, FDA and whomever takes it over is free to charge whatever the "market will bear".
After all, we really aren't a "United" States at all. Look at how different the laws are in each state. Marriage restrictions. Drinking restrictions. Taxation. Whatever. It's really more of a loose federation of territories. Many states even have their own "militia" as well. Why bother with a "national" government at all? Maybe if the folks in Florida and Texas want to send someone to the Moon, they can take up a collection and do it themselves. I'm sure they collect enough $ to compete with the EU, and all of Asia, after all.
You're probably pissed off at me right now, thinking something like "That Dave guy is sure pro-government." Am I? Or maybe you're thinking I'm bashing YOU because I'm assuming you're entirely "anti-government"? Not really. What I am saying is that we should all be careful to draw our lines around the things that we are trying to identify.
As soon as you start bashing an entire thing because one or two parts of it are defective, it immediately makes you a douche-drinking suckhole. It's the kind of thinking that creates and maintains wonderful American qualities like racism, sexism, ageism, and ism-ism. Okay, I need to stop that and get back on the wagon here.If one person in one fast food place treats you badly, does that make the entire chain bad? How about when one of your coworkers (assuming you have a job) acts like an assclown: does that make all of them bad too?
If you stand up during the Pledge of Allegiance, the singing of America The Beautiful, or the National Anthem, then stop and think about what those things really mean. If you "stand up" for something and spend as much time bashing it, your hooking the IV tube up to the douchebag machine and drinking from it. Actually, no, that makes you a turbe-douche drinker.
If you're not already hearing an ever-increasing background sound track to My Country Tis of Thee by now, you need some coffee. After all, nothing is more American than coffee. Especially the $5/cup kind that you stand in line for.
http://www.youtube.com/watch?v=icmRCixQrx8
When people (okay, Americans mostly) draw up "rules" based on limited experiences, they're tossing out babies and bathwater into the wood-chipper at the same time. After all, when you share a comic that implies "government = evil" you're lumping all of it in one bucket of badness.
Here's a thought: Next time your nearby elementary school is attacked by some nut-job who decides to suit-up and shoot at bystanders, how about you not call the police. Call some private firm and negotiate the rate over the phone and have them come out and take care of it instead. Better yet, forget public schools. Make everyone pay for a private school. Same for libraries, recreation centers, parks, water services, trash pick-up, traffic management, emergency medical services, fire department, whatever. Why stop there? Privatize the entire military, FAA, DOD, FEMA, CDC, FDA and whomever takes it over is free to charge whatever the "market will bear".
- Need to stop some terrorists? Get the neighborhood together and do a car wash.
- Need to get a house fire extinguished? Call Joe's Fire Shop.
- Need to negotiate IP rights against China or Korea because they're copying your patents and underselling you? Someone copied your clever trademark? Call Joe's Law firm. (after all, he's much more powerful to bargain with tiny little China).
- Monitor air traffic? Sea ports? Medical research?
- Gun control? Pffft. Give EVERYONE a gun. Wait, did I say "give"? I meant "issue" a gun to everyone, and they can buy their own ammo. And why place age limits on anything? That's another "big government" burden. Driving, drinking, shooting, flying, working.... if you can do it, you're legal. Hard liquor at 6 years old? What could be more American!
After all, we really aren't a "United" States at all. Look at how different the laws are in each state. Marriage restrictions. Drinking restrictions. Taxation. Whatever. It's really more of a loose federation of territories. Many states even have their own "militia" as well. Why bother with a "national" government at all? Maybe if the folks in Florida and Texas want to send someone to the Moon, they can take up a collection and do it themselves. I'm sure they collect enough $ to compete with the EU, and all of Asia, after all.
You're probably pissed off at me right now, thinking something like "That Dave guy is sure pro-government." Am I? Or maybe you're thinking I'm bashing YOU because I'm assuming you're entirely "anti-government"? Not really. What I am saying is that we should all be careful to draw our lines around the things that we are trying to identify.
As soon as you start bashing an entire thing because one or two parts of it are defective, it immediately makes you a douche-drinking suckhole. It's the kind of thinking that creates and maintains wonderful American qualities like racism, sexism, ageism, and ism-ism. Okay, I need to stop that and get back on the wagon here.If one person in one fast food place treats you badly, does that make the entire chain bad? How about when one of your coworkers (assuming you have a job) acts like an assclown: does that make all of them bad too?
If you stand up during the Pledge of Allegiance, the singing of America The Beautiful, or the National Anthem, then stop and think about what those things really mean. If you "stand up" for something and spend as much time bashing it, your hooking the IV tube up to the douchebag machine and drinking from it. Actually, no, that makes you a turbe-douche drinker.
If you're not already hearing an ever-increasing background sound track to My Country Tis of Thee by now, you need some coffee. After all, nothing is more American than coffee. Especially the $5/cup kind that you stand in line for.
http://www.youtube.com/watch?v=icmRCixQrx8
Sunday, December 1, 2013
Black Friday Retarded Retail Report (Front Lines Edition)
(insert some really kick-ass dramatic theme music right now...)
(drink some strong, but cold and stale coffee...)
(inhale as deeply and quickly as you possibly can...)
The employer's name has been withheld to protect the insanity (and my seasonal job). All I can say is that it's a well-known, international, electronics and home convenience store with a location in a mall somewhere in the city of Virginia Beach, Virginia, which is located in the picturesque and sometimes-expensive United States of America. Any specific or explicit references, links, innuendos or mumblings are purely coincidental and should not, will not, and do not, constitute implication or identification, nor indemnification, of any specific retail business, by name or otherwise.
Batteries not included.
It was a blood bath. Okay, not quite, but it almost kind of sort of felt like it. Giggling teenagers, sporting hickeys on their exposed necks, colorful tattoos and piercings, and playfully romping around uncontrolled in the midst of cautious and elderly shoppers. It was horrific. People might have been scared, or something.
To summarize:
(drink some strong, but cold and stale coffee...)
(inhale as deeply and quickly as you possibly can...)
The employer's name has been withheld to protect the insanity (and my seasonal job). All I can say is that it's a well-known, international, electronics and home convenience store with a location in a mall somewhere in the city of Virginia Beach, Virginia, which is located in the picturesque and sometimes-expensive United States of America. Any specific or explicit references, links, innuendos or mumblings are purely coincidental and should not, will not, and do not, constitute implication or identification, nor indemnification, of any specific retail business, by name or otherwise.
Batteries not included.
It was a blood bath. Okay, not quite, but it almost kind of sort of felt like it. Giggling teenagers, sporting hickeys on their exposed necks, colorful tattoos and piercings, and playfully romping around uncontrolled in the midst of cautious and elderly shoppers. It was horrific. People might have been scared, or something.
To summarize:
- Screaming, slobbering babies. Everywhere.
- Drunken customers
- Obnoxious customers
- Customers, customers galore...
- Horny customers (usually in pairs)
- Handicapped customers
- Customers lost asleep in the store.
- Customers testing out the cosmetic mirrors by squeezing their pimples
- Customers having a snowball fight in the store, with sand
- A customer who asked if the warranty covered the item being stolen
- Another customer asking why they couldn't get the Black Friday discount on a Sunday
- Customers asking if the "Fits iPad 2 and 3 only" folding cases would fit their Nexus 7 tablet
- A customer who got visibly upset when I informed him that the indoor/outdoor digital thermometer kit will show the same temperature for both environments, if they ignore the notice on the box that says the remote sensor needs to be positioned OUTSIDE or at least on the glass surface of an outer window. He really had trouble grasping that whole "remote" thing.
- A five year-old girl wandering around the store swinging one of these around like a toy, and singing to it, while her "mother" remained oblivious to it all.
And my personal favorite: The employer who decided, midday on Friday (actually, around 3:30 PM) to block all employee purchases until Saturday. Not that the usual policy of employee's getting a 30% discount was enough, nor the additional Black Friday BOGO (actually, BOGOHO) terms were too generous, but that they BLOCKED all employee purchases. That's a fantastic morale booster.
That was Job "number 3" for me actually. As I'm working (literally) three jobs until January, when I (hopefully) will cut back to just two. Job "number 2", is at a local grocery store, which is part of yet another international corporate chain (see the common pattern here?).
This one however, was really a "Green Wednesday" experience, which is the name I made up for the night before Thanksgiving, when people freak out that they won't have enough food to get even fatter than what they already have in the cabinets to get fat on. American's are the most in-shape people on the planet, after all.
- A box of (thank God) unused Tampons left in the Pizza freezer
- A used, but (thankfully) tightly-sealed baby diaper, left behind a stack of rice bags on a shelf
- I invented a Turkito (a burrito made from leftover Turkey meat, stuffing, green bean caserole and some stale corn burrito wraps, in a microwave oven). Rachel Ray: eat your ___ out.
- I fed my dog so much leftovers she puked it up, and I got watch the other dog eat the puke. Then the cat ate what dog number 2 puked up. In the end, nothing was wasted. So, suck on that Al Queada.
- I discovered I have a passion for cheap Argentinian Malbec wines.
- I discovered that some medications work even better with Malbec wines.
- I discovered that some medications and cheap Malbec wines work on the toilet even better the next morning.
- I discovered that no matter how much I can crack myself up I'm still not getting paid for it.
- I discovered that I need to actually play the lottery in order to improve my chances of winning it.
Anyhow, that's all for now. Back to you, Bob!
Friday, November 22, 2013
What is a Software License?
Is it what you've purchased? (aka. What the purchasing department tracks via a Purchase Order)
Is it what you've installed? (aka. What your inventory software detected)
Is it what's being used? (aka. What your license manager or reporting tools are showing)
Is it a document that defines what, how many, and where you "should" have installed the product? (aka. An SLA or license key file)
Is it a definition of what you are allowed to do with the product? (aka. A license agreement document)
Is it a bundle of products, or a single product?
Is it a standalone license, or a "floating" networked, pool of licenses?
Is it just an idea, or is it a tangible entity?
Can you hold it in your hands, or does it only exist as an arrangement of electrons?
Is it what you've installed? (aka. What your inventory software detected)
Is it what's being used? (aka. What your license manager or reporting tools are showing)
Is it a document that defines what, how many, and where you "should" have installed the product? (aka. An SLA or license key file)
Is it a definition of what you are allowed to do with the product? (aka. A license agreement document)
Is it a bundle of products, or a single product?
Is it a standalone license, or a "floating" networked, pool of licenses?
Is it just an idea, or is it a tangible entity?
Can you hold it in your hands, or does it only exist as an arrangement of electrons?
Thursday, November 7, 2013
If I Were In Charge of Microsoft Right Now...
Yes. This is extremely "pie-in-the-sky" stuff, but I need a mental break from working two jobs every day. I'm sure you can poke a million holes in these suggestions, but whatever... enjoy!
- Stop all work on the Windows OS and call a big-ass meeting to do a massive "reset" on that 400-headed beast. Consolidate and streamline EVERY command utility, API, etc. A common syntax for everything. Eliminate overlaps and redundancy. Retool for true 64-bit (or 128?) rather than the dragging on the current 32/64 band-aid stupidity. Tell partners/vendors "f-u" if you don't comply with the new platform specs. No more backwards compatibility work.
- Redesign the interface so it adapts to the devices, rather than forcing you to use a tablet interface for a keyboard and mouse work environment.
- Give away App-V for free (like MDT and WSUS are handled)
- Get rid of MDOP as a product and make the rest of it (sans App-V) part of the Windows platform.
- Get some fresh faces in the System Center group to retool Configuration Manager to be easier and simpler to (A) install and configure and (B) manage.
- Revisit the "Essentials" idea.
- Deploy physical "Microsoft Store" facilities, like Apple did. Online shopping is cool but tinkering with shit in your physical hands shouldn't be ignored. Oh, and include those nifty-ass Starbucks automated barista machines they have at their own campuses. Those things kick ass.
- Make ads that are funny. If it doesn't make me laugh and cough my beer through my nose, then it needs to go back to the production room and get some more work.
Thursday, September 26, 2013
10 Questions: with David Stein
David M. Stein
Dave 1: Can you name some of your favorite musicians or bands?
Dave 1: You said, his name "was" Brett. What happened? Where is he now?
Dave 2: About six-feet underground. Long, sad, depressing story for another time.
5. Everyone would be implanted with an internal electric shock collar and everyone else would get a free remote activator. That could be pretty interesting indeed.
Dave 1: So, does that mean you're "for" or "against" the HCRA or so-called "Obama-care" bill?
Dave 2: Next question?
Introduction
Really? Is this necessary? If you read my stupidness, then you already know who I "am". If true, you'll probably close this and go back to reading Facebook. If you don't, well, congratulations: you finally reached the end of the Internet. My apologies.
Basic bio stuff: I'm a semi-quasi-successful IT guy working in southeastern Virginia. I've worked in the CAD/CAM world building weird applications for weird business processes, and moved on to "mainstream" IT stuff, dealing with Windows, Configuration Manager, SQL Server, a bunch of goofy
Basic bio stuff: I'm a semi-quasi-successful IT guy working in southeastern Virginia. I've worked in the CAD/CAM world building weird applications for weird business processes, and moved on to "mainstream" IT stuff, dealing with Windows, Configuration Manager, SQL Server, a bunch of goofy
The Questions
Dave: First off: what's with the "M" in your name? Do you feel like it adds distinction, like 'Booker T. Washington' or 'Alfred E. Neumann'?
Dave 2: Alfred was cool. My first cat was named Alfred. Actually, I use my middle initial to differentiate my books on Amazon from another "David Stein", who sells books about Bondage and S/M stuff. No offense intended towards anyone who likes that stuff, but I got tired of being asked if that was me. The stuff I write about is nowhere near as interesting as that, I'm sure.
Dave 1: How would you describe what you do for a living?
Dave 2: Lucky!
Dave 1: Why?
Dave 2: I say 'lucky' because I'm a developer by nature, working in roles as analyst/engineer/administrator, but using developer experiences to automate the shit out of anything I can.
Dave 1: Can you name some of your favorite musicians or bands?
Some of my favorite musicians would have to include Frank Zappa, Jeff Beck, Pink Floyd, Red Hot Chili Peppers, and U2. But I like a wide range of music, from Miles Davis and Stanley Clark, to Bob Dylan, to Eminem, wherever he is now. That's all mostly due to having once been an aspiring musician.
Dave 1: Oh yeah? What instrument did you play? And what particular situation can you recall that was funny or interesting from that time?
Dave 2: I played drums and percussion. I also took piano lessons, so I dabbled a bit. Some rock, some pop, some traditional Jazz also. I sat in with a country band once also.
I suppose one of my favorite situations would probably have to be when we were playing 'Hot for Teacher' (Van Halen) in a crowded club one night. Our lead guitarist was coming out of the big solo, doing his scale climb, where the drums follow along, going from a 4/4 thing through a 2/3 or 3/4 segment, whatever... And one of my sticks slipped away and nailed him directly in the back of his head. The spotlight was on him too. Perfect hit. Talk about playing the wrong note at the wrong time. Sorry, Clint. No hard feelings dude.
I suppose one of my favorite situations would probably have to be when we were playing 'Hot for Teacher' (Van Halen) in a crowded club one night. Our lead guitarist was coming out of the big solo, doing his scale climb, where the drums follow along, going from a 4/4 thing through a 2/3 or 3/4 segment, whatever... And one of my sticks slipped away and nailed him directly in the back of his head. The spotlight was on him too. Perfect hit. Talk about playing the wrong note at the wrong time. Sorry, Clint. No hard feelings dude.
Dave 1: What drew you away from music and into technology and computers?
Dave 2: It was the early 80's, and I needed a job. Mostly for gas and beer, at the time. So many priorities back then, you know? Construction didn't pay enough, nor did dish-washing, lawn-care, retail sales, or painting, so I went into Drafting. After a year doing manual drafting, the whole CAD (computer-aided design) thing came along. At first it was mainframes and workstations, then PC's came along, and then Windows and networking.
While doing the PC CAD thing, I fell in love with AutoCAD and AutoLISP. It was the first time I was exposed to being able to tweak something to do what I really wanted. I tried that with my dog, but he wouldn't do anything I asked unless I tossed food at him. AutoLISP led to years of programming, climbing around on Navy ships, more programming, drinking and traveling, and more programming. But also a lot of drinking. It was the early 80's after all.
Dave 1: What kinds of things did you do with AutoLISP and AutoCAD back then?
Dave 2: Shipbuilding has its own unique drafting standards. Everyone thinks they are drawn the same way as houses and building or machine parts. But, it involves its own specific way of doing dimensions, callouts, views, notes, references, and materials lists. Even the sheet border formats are unique. It got really annoying having to constantly change everything manually, or copy and edit. So I wrote some utilities and menus to do it the "shipbuilding way", and that led to a new career path for me.
Dave 1: So... programming did it? How did you end up doing Windows, AD, SQL and SCCM?
Dave 2: Shipbuilding has its own unique drafting standards. Everyone thinks they are drawn the same way as houses and building or machine parts. But, it involves its own specific way of doing dimensions, callouts, views, notes, references, and materials lists. Even the sheet border formats are unique. It got really annoying having to constantly change everything manually, or copy and edit. So I wrote some utilities and menus to do it the "shipbuilding way", and that led to a new career path for me.
Dave 1: So... programming did it? How did you end up doing Windows, AD, SQL and SCCM?
Dave 2: Hoo-boy! How much time do you have?
(Dave 1: I'm not going anywhere. I am you after all, so, uhhh...)
Ok. Well, you asked, so... (Takes a reeeeeally long inhale)... While working at a particularly large shipyard, I was both their AutoCAD operations, and customizing it all to fit shipbuilding needs. It was a lot of work, but it was fun. One of the guys in the infrastructure team brought donuts in a lot, so I brought jokes and somehow we got along (and I got fatter too). His name was Brett. He was a really cool guy too. Rest his soul.
Anyhow, he was rolling out SMS 2.0, which was really new at the time, and he asked if I wanted to work with him to knock out two of the biggest hurdles at the same time: a thousand seats of AutoCAD and a new deployment system.
Long story short: he got me into thinking about expanding my programming and introduced me to thing like WMI, WBEM, SQL, DCOM, VBscript, and larger perspectives as well.
Dave 1: You said, his name "was" Brett. What happened? Where is he now?
Dave 2: About six-feet underground. Long, sad, depressing story for another time.
Dave 1: How many questions is that now?
Dave 2: You're asking me? Or, ugh, you? I mean... never mind. Continue?
Dave 1: Describe your home life.
Dave 2: A hard-working, creative and loving wife, of 25 years. Three crazy daughters, a wacky son, two weird dogs, and a cat that rules the humans around her. Our kids are ages 14 up to 23. All still at home. Still on my cell plan too, which is why I'm always working and still broke.
Dave 1: Do you consider yourself to be a good dad?
Dave 2: You'd have to ask them that question.
Dave 1: Ok, moving along. You said you're broke? How's that? You have quite a few books on Amazon, a fairly decent blog, and a good job, no?
Dave 2: Yeah, well. It's complicated. I don't make much on book sales actually. Maybe I should mix in some kinky S&M crap with my computer topics to pump the sales up? Who knows.
Dave 1: What aspects of current technology and the tech industry still excite you? Which of them do you feel have been a disappointment?
Dave 2: Ooh! Good questions!
On the good: Open source is still relevant, even with billions being spent to silence it all. Social media. Proliferation of cellular coverage. Mobile devices. Maturing API stacks. Faster and cheaper hardware.
On the bad: Social media. The misguided strategies of the big players. Over-hyped rushing to the "cloud". Too many web tech standards. Too many colliding acronyms.
Dave 1: Wait a minute. You mention "social media" for both good and bad?
Dave 2: Yep. I did. Good for catching up with long-lost friends, schoolmates, teammates, neighbors, and family. Bad for stirring up drama though.
Dave 1: Sheesh. Tell me about it.
Dave 2: I just did.
Dave 1: Oh, yeah right. What's with your dislike of the "cloud" trend?
Dave 2: Same as anything else: Everyone runs to it without stopping to ask why. It's great for some things, like Microsoft Excel is, but when businesses grab it like it's the cure-all for every problem, they run into problems. Sometimes that "solution" creates more problems than it solves, and it can be difficult to turn around and "go back" as well.
Dave 1: If you had absolute control of America long enough to pass a short list of irrevocable laws, what would they be?
Dave 2: Same as anything else: Everyone runs to it without stopping to ask why. It's great for some things, like Microsoft Excel is, but when businesses grab it like it's the cure-all for every problem, they run into problems. Sometimes that "solution" creates more problems than it solves, and it can be difficult to turn around and "go back" as well.
Dave 1: If you had absolute control of America long enough to pass a short list of irrevocable laws, what would they be?
Dave 2: (laughs quietly for almost a full minute...) Ok...
1. Free, High-speed internet to every home, apartment, school and business.
2. Free, high-speed rail service between every city with at least 400,000 citizens.
3. Bumperstickers which aren't funny would be punishable by public beatings.
4. Repeating any rumor, as if it's fact, without passing a cross-examination test to prove you read the actual source facts, would be punishable by slow, painful, death. For instance, when people blabber on "for" or "against" the so-called "Obama-care" bill, or some spending bill, whatever, but none of them actually read the bill itself. If you haven't RTFM (ok, RTFB), then STFU, or submit to being electrocuted in the crotch for two hours on live TV while being force-fed liquefied used kitty litter.
5. Everyone would be implanted with an internal electric shock collar and everyone else would get a free remote activator. That could be pretty interesting indeed.
6. I'm still working on number 6. Next question?
Dave 1: So, does that mean you're "for" or "against" the HCRA or so-called "Obama-care" bill?
Dave 2: Next question?
Dave 1: Last one. What would be your ideal epitaph?
Dave 2: (rubs chin and smiles) "I almost made it!" My second choice would be what my brother suggested, which is "I should have cut the green wire."
Dave 1: Ok, folks. I hope you enjoyed this interview as much as, ummm, "we" did? For more info, search Dave out on LinkedIn, 4sysops, MyITForum, and Amazon but watch out for that other David Stein.
Until we meet again: Love. Peace. Namaste, and all that.
Wednesday, September 18, 2013
Knowing Which Seeds to Water
(Warning: I've had some coffee today)
In The Beginning
In 1990, at the age of 26, I worked as a drafter for a small Naval engineering firm in Virginia. It was my third job in the field of naval design, and I was assigned to work in the Piping Systems Division with maybe two dozen others, in support of contracts for overhauling U.S. warships. It was during this time that PC-based CAD entered the foray in the defense industry. ThisCAD and ThatCAD were everywhere, but AutoCAD was the eventual, and clear winner. Until then, everything with "CAD" in the name wasn't even considered unless it ran on UNIX-powered hardware.
While learning to use this new "AutoCAD" tool, I tripped over something and looked down to realize that inside this little product was a shiny gem called "AutoLISP". A customization programming tool, built right into the product! Having tinkered with CMD and Batch scripting for MS-DOS and Windows, I was addicted from that moment on to programming. Mainly because it made it possible to draw and "create" visible objects on the screen, rather than a bunch of numbers and text.
After a few weeks, I built some menus, functions (or "routines", as they were often called then), and eventually wrapped them in dialog forms and prettier stuff. After sharing them with my coworkers, I began to get feedback and ideas started coalescing like a tropical storm into a hurricane. The momentum continued to build and within a few months I had a complete "design package" for automating much of the tasks involved with creating and validating engineering and design drawings for piping systems.
Auto-Something-or-other
Not long after that threshold was crossed, I spread out into HVAC systems, and eventually into the other primary system groups involved with nautical engineering: Structure, Outfitting, Machinery, Electrical and Electronics. Then it was on to building the top of this strange pyramid: Notes, References, Sheet Formats, Materials Lists, Tables, and so on. In much the say a Lego kit ends up becoming a city with elevated monorails and skyscrapers around a kid's room, I ended up gluing in data files, database tables and views, symbol tables, icon files, drawing parts (block inserts, XREFs, etc.). Building on top of what a predecessor from our New York office had started, it became an entirely new animal.
My boss was supportive, as was the Department Manager, and the Division Manager. But once it cleared the cloud layer, things got less clear. I never asked for a raise or a promotion, oddly enough. All I asked for was the approval to tap a few key "power users" in each department to form a "team" to help improve this automation tool even further and faster. Silence.
In 1996, I was contacted by a much-larger company, a nearby shipyard, to take on a newly created role of "AutoCAD Systems Manager" for an entire Division. That meant a lot of things at once for me: Automating the deployment (installation), configuration, maintenance and licensing of AutoCAD and AutoCAD Mechanical Desktop to roughly 1,300 users. There were other Divisions, but they were tied to UNIX products and rebuffed any consideration of anything that ran on a scruffy PC. This offer also meant I'd take over licensing administration (i.e. FLEXlm), and my prized role: Customization. Oh yeah, it also meant a considerable pay increase and better benefits, but customization was what I had my eyes on the entire time.
Project: Mariner
Within a few months of that new job, I began building an entirely new suite-based, collection of design automation tools to run on AutoCAD and MDT for Piping, HVAC, Mechanical, Hull-Structure, Hull-Outfitting, Electrical, and Materials. This new beast grew a beard and a deeper voice and eventually was named "Mariner". A fitting name I thought. I sure get wrapped around the axle when it comes to choosing a name for software projects, but that's for another story.
This process continued to grow and I was allowed to form an unofficial "team" to help maintain and improve it as well. Once again, I never asked for a raise or promotion, but things seemed to progress much more easily.
Sometime in late 1999, this shipyard began contracting in designers from local firms to handle the capacity of work going on. The contractors were required to learn this new abstraction layer, so I embarked on developing a training guide, a training course and even was authorized to issue training certificates for completion of the training. Seriously, they printed some 1400 books with color graphics and sturdy permanent binder edges. Nifty stuff!
Project: ShipWorks
In early 2000, one of the contractors asked if they could license this "Mariner" product to use back in their offices. The rationale at the time involved a lack of physical space at the shipyard to bring in any more contractors, while the workload continued to rise. I approached the corporate overlords, their legal masters and the contracts department gurus and soon there was a "first-ever" licensing contract produced to allow their "partners" to use this product. Until then, no other such vehicle had existed, or so I was told. Then, I inquired about approaching Autodesk or some other (no defunct) software vendor, to help take it to the next logical level: external marketing. There was interest from nearly all of the outside contracting firms, as well as several software vendors. The company said: "NO. We are not a software development company."
Growing tired of the lack of management support, I accepted an offer to work for a local Autodesk product reseller. I submitted my two-weeks notice and packed my belongings to move on to yet another employer. On my last Friday, I received a phone call from the contracting firm that had initially approached our company about licensing Mariner. They heard I was leaving and they counter-offered and, me being stunned and shocked, I accepted it. I went to that new employer and, again, started development on a totally new product, incorporating all of the lessons-learned from the Mariner project. This animal grew into something called "ShipWorks". Much to the chagrin of Autodesk, it was not ever intended to run on Solidworks, nor was it ever attempted. Still, they were obviously not too happy about the "works" suffix. Just an odd side note now, I think.
That leg of my journey into the software technology world is where I officially transitioned from a mostly-engineering environment into a mostly-IT environment. I absorbed managing Windows Server, SMS and Configuration Manager, WSUS, RIS and WDS and a whole bunch of other weird things that I found interesting and helpful, and which helped cut costs and make for a better computing environment.
In this new role, I was given a team, management support, resources and things finally to be on a good track. Then in 2007, the company was sold and split apart. I ended up bouncing to a consulting firm, which lasted about three months, when the economy tanked, and I had to make ends meet doing side work for a few months before crawling on my knees back to the shipyard and beg for my job back. They graciously accepted.
From here on, I haven't touched AutoCAD much at all. Most of the work I've done since involves things like ASP or PHP, along with SQL Server, Oracle, Active Directory, SMS or Configuration Manager, Inventory systems, Service Request systems, and so on. Basically, gluing things together horizontally with a big bucket of sticky web application goo.
Looking Back
Every one of the places I've worked at, I've built something custom to help them operate more efficiently and tried to make the users happy with the results. In every case, my immediate supervisors were very supportive. In every case, when it went above my immediate supervisors things got shaky and less reaffirming. The support and reinforcement began to vaporize the higher I went.
The Takeaway
Over the past twenty-odd years, I've seen more potential wasted because someone decided a project was not worthy of basic consideration. Not even giving it a second thought. The results could have been astoundingly helpful for a lot of people and businesses. Too quick to judge, was always the culprit to killing the dream before it could begin to take shape. I'm writing this today because I still see this happen too often, in too many places.
If you have a lone developer, or a small team of developers, within your business, official or not, and they are actually producing useful things, support them. Especially if they don't ask for monitory compensation, but they simply want to see that management cares and wants to help them push it further. Maybe it's outside of your "core business" comfort zone. Maybe you never considered your business to include this mysterious thing called "applications development". Try making it work anyway. You say you have "gut instincts" for business, well, use them. You might be amazed what good can come from it. I'm not suggesting you rubber-stamp every app-dev project without checking on it's merits. Verify and validate them all. But just don't reject them simply because they involve "application development". That's an unforgivable crime of business.
Cheers.
Subscribe to:
Comments (Atom)















