"Software is eating the world." Have truer words ever been spoken other than these words by Marc Andreessen?

I've recently been immersed in a number of home automation projects (lights, heating/cooling, presence detection, and more). I was reflecting on what made all of these automations possible: the drastic increase in the amount of software present in the home. As I was reflecting on this, I realized how different my house is in this respect compared to the house I grew up in.

Now, I'm not saying I'm old. More like, the rate of digitization in the world around us has happened at such a pace that even in my short lifetime, the changes have been deep and wide.

This blog post is a tour of things in my house that are software operated that were not software operated in the house I grew up in. For my purposes here, I define "software operated" as any device that has software or firmware that is upgradable either by me or through an over-the-air process that the device or its cloud service initiates. I'm leaving out "obvious" items like laptops, tablets, and mobile phones.

Often in my career I have to make an estimate about the so-called "level of effort" (LoE) to do a thing.

• What's the LoE for me to do a demo for this customer?
• What's the LoE for me to help respond to this RFP?
• What's the LoE for me to participate in this conference?

The critical metric by which I usually have to measure the LoE is time. People, equipment, venue, materials, and location are rarely ever a limiting factor. Time is always the limiting factor because no matter the circumstance, you can't just go and get more of it. The other factors are often elastic and can be obtained.

And oh how I suck at estimating time.

As soon as the question comes up, "What's the LoE for...", I immediately start to think, ok, if I am doing the work, I can do this piece and that piece, I can read up on this thing and get it done with slightly more time invested, and then yada, yada, yada... it's done!

What I don't account for is the human element. The unexpected. The fact that we're all different and team members will go about their work in their own way. In other words, the soft, non-technical aspects of doing the thing.

Along these lines, here are 9 things that I would be wise to consider when making time estimates in the future.

I've been asking myself an uncomfortable question lately: "Can IT certifications become a liability? Have I reached a point where my IT certifications have become a liability to me?"

Well, it looks like another major item will get struck from my bucket list this year. I've been accepted to present at Cisco Live in Las Vegas this summer! 👊 This session is designed to walk through an enterprise network and look at how EIGRP can be engineered with purpose to best suit the needs of the different areas of the network. I will focus a lot on stability and scaling EIGRP and will show the audience how, where, and when to leverage common EIGRP features such as summarization, fast timers, BFD, and wide metrics.

Cacti is a "complete network graphing solution" according to their website. It has also been a thorn in my side for a long time.

See what I did there? Thorn... because it's a cactus... never mind.

When Cacti is in a steady state-when I could get it to a steady state-it was good. Not great, because there was a lot of effort to get it into what I consider "steady state", but good. The rest of the time... thorny.

There are five major things that have driven me up the wall. In no particular order:

I had just lost the RAID array that hosts my ESXi data store. I didn't yet know that's what had happened, but with some investigation, some embarrassment, and a bit of swearing, I would find out that an oversight on my part three years ago would lead to this happening.

I recently decided it would be fun to upgrade the hardware on my main OpenBSD machine at home (because, you know, geek). These Intel NUC machines are pretty interesting. They are pretty powerful, support a decent amount of RAM, certain models support internal storage, and they are very low power and low noise. Perfect for a machine that is a shell/email/development box.

There's a lot of information on the intertoobs about getting ssh-agent "working" in OS X and even more articles about when and how the stock behavior of ssh-agent changed (mostly with respect to how ssh-agent interacted with the Keychain).

This article doesn't cover or care about any of that.

This article is concerned with:

• Enabling ssh-agent in such a way that I can "ssh-add" in one terminal window and that same agent (and the loaded keys) is available in all of my other terminal windows.
• Enabling use of ssh-agent from MacPorts and/or Homebrew and not the older ssh-agent that OS X ships with in /usr/bin.
• To avoid having to put my keys in the Keychain (just a matter of preference).

Presenter: Paul Lysander, Technical Marketing Engineer, Cisco

Presenter: Fred Niehaus, Technical Marketing Engineer, Cisco Wireless Networking Group