DaedTech

Stories about Software

By

The First DaedTech Digest

I mentioned this idea in a post I wrote the other day, the idea of a digest style of post.  So today, I’d like to give it a try.

You see this sort of thing a lot, all over the place.  So-called planet sites have been around for a long time, aggregating community-related articles into a single place.  Examples include one of my personal favorites, the Morning Brew.

There’s just one difference in what I’m proposing.  Instead of gathering stuff that others have written, I’m going to digest the stuff that I’ve written.  In the last year, we’ve turned my paid blogging for other sites into a tech content business, taking blogging from a side hustle and hobby to a professional gig.  So, I write a lot of blog posts.

Historically, I’ve simply cross posted these with canonical linking, leading in with “editorial note: I originally wrote this post for…”  But I’m thinking of taking DaedTech in a bit of a different direction than just generalized software-oriented blog posts.  More on that later.

The point here is that, instead of pushing one of these cross posts out per day, I’m going to do a single digest post per week containing posts that I’ve made.  I have about 90 backlogged drafts in my folder, so at first it’s going to be posts I made some months back.  But sooner or later, I’ll catch up and give the posts I’ve published in the last week.

But anyway, without further ado, here’s the digest.

Some Posts to Check Out

  • This is a piece that I wrote for the Monitis blog.  It’s about threat modeling and the woes of being an e-retailer and guarding yourself against criminals and ne’er do wells.
  • I wrote a post for TechTown that was a primer about unit testing in C#.  It gives you a back to basics explanation, the value proposition, and the simplest imaginable examples of writing unit tests.
  • This is another post that I wrote for Monitis. It’s about the C# IEnumerable construct and how, if you misunderstand it, you can kill your site’s performance.  This has to do with how IEnumerable can encapsulate deferred execution, and that it only promises a strategy for obtaining items, rather than giving you those items.
  • I wrote this post for SubMain.  It’s about how something that’s seemingly inconsequential — spell checking your code (specifically, C#) is more important than you might think.  There are subtle things to consider that you might not have considered.
  • This post is actually going to become part of Microsoft’s official documentation!  Seriously, no kidding.  Bill Wagner wrote to Patrick and I about this post, and it’s now in their documentation build on Github.  Anyway, I wrote it for NDepend, and it’s a walk back through past major version of C#, reflecting back on nearly 2 decades of the language.  It was a fun journey down memory lane.

And, that’s it.   Happy reading, and happy Friday!

By

The ROI for Security Training

Editorial note: I originally wrote this post for the ASPE blog.  You can check out the original here, at their site.  While you’re there, check out their catalog of online and in-person training courses.

When it comes to IT’s relationship with “the business,” the two tend to experience a healthy tension over budget.  At the risk of generalizing, IT tends to chase promising technologies, and the business tends to reign that in.  And so it should go, I think.

The IT industry moves quickly and demands constant innovation.  For IT pros to enjoy success, they must keep up, making sure to constantly understand a shifting landscape.  And they also operate under a constant directive to improve efficiency which, almost by definition, requires availing themselves of tools.  They may write these tools or they might purchase them, but they need them either way.  In a sense, you can think of IT as more investment-thirsty than most facets of business.

The business’s leadership then assumes the responsibility of tempering this innovation push.  This isn’t to say that the business stifles innovation.  Rather, it aims to discern between flights of fancy and responsible investments in tech.  As a software developer at heart, I understand the impulse to throw time and money at a cool technology first and figure out whether that made sense second.  The business, on the other hand, considers the latter sensibility first, and rightfully so.

A Tale of IT and the Business

Perhaps a story will serve as a tangible example to drive home the point.  As I mentioned, my career background involved software development first.  But eventually, I worked my way into leadership positions of increasing authority, ending up in a CIO role, running an IT department.

One day while serving in that capacity, the guy in charge of IT support came to me and suggested we switch data centers.  I made a snap judgement that we should probably do as he suggested, but doing so meant changing the budget enough that it required a conversation with the CFO and other members of the leadership team.

Anticipating their questions and likely pushback, I asked the IT support guy to put together a business case for making the switch.  “Explain it in terms of costs and benefits such that a non-technical person could understand,” I advised.

This proved surprisingly difficult for him.  He put together documentation talking about the relative rates of power failures, circuit redundancy, and other comparative data center statistics.  His argument in essence boiled down to one data center having superior specs than the other and vague proclamations about best practices.

I asked him to rework this argument, suggesting he articulate the business case using sort of a mad lib: “If we don’t make this change, we have a ______% chance of experiencing problem _______, which would cost $_______.”

This proved much more fruitful. We made the case to the CFO and then made the switch.

Read More