All Posts in Technology

|In: Industry Commentary|Last Updated:

What’s Microsoft waiting for?

Somehow or other, as, over the past four decades, its Office suite of applications has evolved into a powerhouse force for individual productivity and group collaboration …

Somehow or other Microsoft never bothered to fix an annoying and easily fixed Excel “feature” (as in, it isn’t a bug; it’s a feature). Namely, just how many versions of blankness do users need (maybe 2 but I doubt it) and why are they so hard to find?

There are, so far as I can tell:

  • String nulls: Cells that have never been touched but are formatted as character strings.
  • Numeric nulls: Likewise, but as numbers.
  • The other numeric null: What you get after unchecking File/Options/Advanced Show a zero in cells that have zero value.
  • “”: Empty character strings.
  • “ “: The blank character.
  • Zeroes formatted to not display anything in the cell.

By themselves a few of these might actually be useful. What makes the bad outweigh the good is that there’s no one test that reveals them all.

Surely Microsoft could provide (for example) a modified ISBLANK() function that returns a TRUE value for any sort of blank cell; likewise it could add a FILE/OPTIONS/ADVANCED parameter that unifies the behavior of all blanks; or add a parameter to any function that handles blanks telling it to either ignores blanks of all types, or treats them all as zeroes. That would save legions of Excel jockeys from having to rely on =OR(ISBLANK(A1), A1=””,A1=” “,A1=0,LEN(A1)<1) or some such formulaic nonsense.

Why do we have this mess? I can only speculate. I imagine it’s rooted in one of the laws of organizational dynamics: When the problem is diffuse and merely annoying there’s always something more important to work on instead.

While I’m beating Microsoft up over this admittedly less-than-world-shaking grievance I have to admit: I’m guilty too. In my case the problem I’ve let fester is (was) failing to update WordPress to a supported version of PHP. I’ve known for a couple of years that the platform needed updating. But as I’m no longer a good enough programmer to troubleshoot any problems that might emerge from the process I decided to leave well enough alone.

Until this week (and let me know if you spot any glitches that need fixing – thanks!)

So I’m as guilty in my own way as Microsoft is in its way, but on a small enough scale and with such a small number of victims if it goes wrong (one, namely, me) that I can handle the remorse. But at the other end of the scale I know of Fortune 500 companies running applications on out-of-support server hardware and operating systems … thousands of them … with no path to safety because procrastination has saved them money every year for the past decades or more.

Not to mention all the other large but not enormous enterprises for which infrastructure maintenance is never quite important enough, right up until an attack takes their core applications down for a week or more.

Manufacturing mavens figured out a long time ago that preventive maintenance is less expensive than break/fix maintenance. That the IT infrastructure is harder to understand than the motors, gears, pulleys, and belts that constitute a modern factory doesn’t change the principle.

Bob’s last word: In IT, maintaining healthy platforms and infrastructure isn’t best practice.

It’s the minimum standard of basic professionalism.

Bob’s sales pitch: There’s a reason I named this blog “Keep the Joint Running.” It’s because of Principle #7 of the KJR Manifesto, which says: Before you can be strategic you have to be competent.

It isn’t the only principle worth adopting, either. Be a person. Buy yourself a copy. If you already have a copy, write an Amazon review. KJR needs your support. This is one way of providing it.

Comments

|In: App Dev Methodologies|Last Updated:

Good golly Miss Molly!

It was bad enough when folks thought the original version of DevOps … developers and IT operations actively collaborating … was an original idea.

Note to everyone in the IT universe: No matter what your context is, and who you’re working with, you didn’t invent collaboration. If you want credit for originality, COME UP WITH SOMETHING ORIGINAL!!!!

Whew. I feel much better now.

As for DevOps, at least it evolved into something reasonably original, or at least something reasonably radical. To save you a few minutes of googling, in its current form DevOps has contributed two important ideas. The first is that development teams should always leave software in a deployable state (the deployment part of “Continuous Integration / Continuous Deployment”).

The second, which is foundational for all things Digital, is that automation should be the default no matter what process or practice you’re dealing with.

So far so good, and even better after Dave Kaiser and I layered in the idea of BusOps – that the collaboration between IT Operations and business Operations is just as important as the various collaborations IT developers should involve themselves in. (Want a more complete account? Oh, c’mon, you can afford the book).

But then someone had to invent DevSecOps. And CloudOps. MLOps (machine learning).

And now (drumroll) … we have FinOps, as in, someone should pay attention to a company’s cloud expenditures – “Cloud financial management,” in the words of the FinOps Foundation, which suggests that somewhere along the line, “Ops” and “Cloud” became synonyms.

Rather than just fixing the name (CloudFinOps … CFO for short?) let’s start right in on critiquing the FinOps Foundation’s six guiding principles:

Principle #1: Teams need to collaborate.

KJR perspective: Well, yes, that is the definition of “team.” Not original. Not even interestingly unoriginal.

Principle #2: Business value of cloud drives decisions.

KJR perspective: The business value of something should drive business decisions? No kiddin’ Dick Tracy. Not original. Not even interestingly unoriginal.

Principle #3: Everyone takes ownership of their cloud usage.

KJR perspective: Sure, if you want to slow everything down to a crawl. Certainly, those who consume cloud resources of any kind shouldn’t treat them as free. Yes, everyone should have enough awareness of what cloud stuff costs that they don’t make stupid decisions. But implementing technology-enabled business change is hard enough without worrying about nickel-and-dime stuff every step of the way.

Principle#4: FinOps reports should be accessible and timely.

KJR perspective: Oh, now we need FinOps reports? That means we need an organization to produce them. Which means … see Principle 3, because who’s going to own the costs of staffing and provisioning this new, emerging bureaucracy?

Principle #5: A centralized team drives FinOps.

KJR perspective: Of course it does. See the KJR perspective for Principle #4. Plus, this ignores a fundamental rule of organizational dynamics, which is that while centralization drives efficiency through economies of scale, decentralization is what drives innovation, by removing organizational barriers to rapid decision-making.

Principle #6: Take advantage of the variable cost model of cloud.

KJR perspective: We covered this ground a long time ago (“A cloud spiral of death,” 11/5/2012). If your demand for computing resources varies enough that being able to add … and shed … capacity as the situation calls for it matters, the public cloud’s variable cost model is downright nifty.

But costs that are variable are only useful when demand is variable. If your demand is steady and predictable, owning your own computing infrastructure might be more economical because you don’t have to tack on enough margin to turn a profit.

Bob’s last word: No question – organizations that operate without discipline usually end up collapsing under their own bloat. That doesn’t mean discipline should be imposed by layer upon layer of outside reviewers. All that does is create a high-friction enterprise.

An effectively disciplined organization, in contrast, comes from establishing a culture of discipline.

Culture is an organization’s lane markers. Governance and controls are, or at least should be, its guard rails.

If you hit them, something is already very wrong.

Bob’s sales pitch: Want practical guidance on how to engineer your organization’s culture? You need (here’s a surprise!) a book. Namely, you need Leading IT: (Still) the Toughest Job in the World. Chapter 8 will provide you with all the techniques you need to make this happen.

Comments