When my children were young, I offered them two alternatives. They could either make the same mistakes I made growing up, or they could learn from my mistakes and make a bunch of new ones instead. I’ll let you guess. Heck, I can only guess myself.

But I don’t have to guess about DevOps, where some practitioners are making mistakes IT learned to avoid decades ago.

In particular, we learned IT shouldn’t release application changes into the wild without: (1) conducting comprehensive regression tests if the application change in any way alters system integrations; and (2) providing at least delta communication, and in many cases delta training, if the user interface changes.

Wait! Why am I wasting your time with 30+ year old wisdom?

I know it looks like I’m changing my name to Captain Obvious. But while I know you know better than to engage in these IT worst practices, that doesn’t mean your technology vendors do too.

If you’ve read anything about DevOps, you know CICD is a key element. But many vendors, having invested significant money and effort into adopting DevOps as How We Do Things Around Here, only got three of the four letters right: Continuous, Integration, and Continuous.

But they read somewhere that the “D” stands for Deployment, and, with the enthusiasm of the converted, gave the matter no further thought.

As a regular KJR reader you know the difference between a release and a releasable build, and with that the difference between Continuous Integration/Continuous Deployment … appropriate for eCommerce applications where what changes is the customer’s shopping experience … and Continuous Integration/Continuous Delivery, the model that works for applications whose purpose is to support internal processes and practices.

Just in case: The difference between delivery and deployment is simple: Delivery installs to the staging environment; deployment installs to production.

It’s past time to make sure your vendors deliver to staging and don’t make you vulnerable to vendor-DevOps-driven unmanaged deployments.

Start with your contracts. Do they prohibit your vendors from deploying changes to the UI and application interfaces without your permission? If not, start negotiating the requisite contract changes.

SaaS providers are particularly notorious for unmanaged deployments, because you can’t block changes they install on their servers with your defenses. But increasingly, providers of customer-installed COTS are adopting DevOps practices too.

This doesn’t make it okay to go back to … or, in many cases, to persist in … the outdated practice of staying on stable versions as long as possible. Staying current or nearly current is no longer one choice among many. In an age of state-sponsored and organized-crime-sponsored assaults on your information systems, staying current or nearly current is now the choice, not a choice.

So let your vendors off the hook, and accept a deadline for implementing new releases. Your vendors should give you ample time to test. You should let them retire ancient versions.

This doesn’t just apply to the IT vendors you have, either. Every time you go through a solution selection, make sure you include your requirement that the vendor doesn’t push changes into your production environment without your knowledge and consent.

Second: It’s time to automate regression testing. Yes, setting it up is painful and expensive. For that matter, maintaining the automated test plan is no picnic either.

The alternative, though? There’s an old, old rule in IT, which is that you always test. Professionals test before putting software in production. Amateurs test by putting it into production.

And we’re well past the time when just grabbing a bunch of end-users and having them bang on their keyboards for an hour or two will give IT a passing grade.

Third: Make #2 less expensive by cleaning up your interface tangle once and for all. While reliable industry statistics are hard to come by (strike that — they’re impossible to come by), anecdotal and conversational evidence suggests that the ongoing cost of maintaining an ad hoc collection of point-to-point interfaces can, over time, overwhelm IT’s ability to implement new applications and application changes.

To put a bow on it: How could DevOps proponents make such an elementary mistake as conflating delivery and deployment? It’s sadly easy to understand. As a member in good standing of the KJR community, you understand there’s no such thing as an IT project.

But we’re still in the minority. The IT pundit class thinks moving from projects to products is an exciting transformation.

If the job is done when the software runs, CI/CDeployment is fine and dandy.

If it isn’t … choose the wrong goal and wrong practices are inevitable.

Aw, cripes. Another one?

I’m talking about the KonMari method, how annoying fads like this are, and the likelihood we’ll have to deal with someone who thinks it’s clever to put us on the defensive by pointing out our unenlightened failure to apply it to our day-to-day business decisions.

In case you’ve been spared from awareness of this silly bit o’ fluff, it’s a methodology, invented by one Marie Kondo, for simplifying your life. The way it works: (1) Gather together all of one’s belongings, one category at a time; (2) keep only those things that “spark joy”; and (3) choose a place for everything from then on.

I tried it. I kept only those furnishings that sparked joy. My garbage cans didn’t make the cut. Out they went, and by the way, have you ever tried to throw a garbage can in the garbage? It’s a tricky proposition.

I conducted this trial as a thought experiment — my garbage cans are still here — because seriously, people fall for nonsense like this?

Understand, I’m severely jealous. Armed with such a patently preposterous proposition and adroit self-promotion, Marie Kondo, at the ripe old age of callow, has millions of devotees while I, saddled with a self-imposed requirement of subjecting ideas to at least 15 seconds of close scrutiny before sharing them with you, enjoy a more limited level of celebrity.

But never mind my virology failures. This is a column about preparedness, as in how will you respond when someone proposes that as a manager you should be applying the KonMari method to your areas of responsibility?

The question might be directly KonMari. More likely, it will be KonMcKinsey in phrasing instead (“prune underperforming assets”).

And by the way, in both locutions the underlying concept isn’t entirely stupid. If the point is to take a fresh look at all your stuff and recognize what you have in your closets, shelves, and dressers that’s only there because keeping it is easier than throwing it out, then yes, throw it out.

Based on our experience moving from a suburban townhouse to a downtown condo with substantially less storage, I can tell you many of our possessions were items we had no particular need for, and that’s after we jettisoned several hundred books we’d already read and would never read again.

In your business responsibilities, you also have “assets” where taking a fresh look isn’t unreasonable. The problem is the ROI (return on investment) mentality that’s usually associated with such evaluations.

By “ROI mentality” I mean the requirement, drilled into the heads of most managers like some form of business trepanning, that anything for which we can’t prove a direct financial return provides only “intangible benefits.”

This is such a nice turn of phrase, don’t you think? Technically, it means the benefits are non-financial in nature. But it’s hard to avoid the conclusion that it’s wording carefully constructed to put managers advocating for these things on the defensive. We aren’t differentiating between financial and non-financial benefits. We can see, touch, and feel things that are tangible. Intangible is just one short step from imaginary.

But … isn’t insisting that everything produces a profit a good idea?

In a word, no. In several words, organizations aren’t portfolios of uncoupled assets. They’re assemblages of interconnected functions … services if you’re in an SOA frame of mind … that turn raw materials, also known as inputs, into the organization’s work products, also known as outputs.

Management’s job is to make sure each asset — each service, sub-service, sub-sub-service, and microservice — works as it’s supposed to in order to keep the joint running. Asking whether each asset provides proper value and ROI just misses the point entirely.

So if someone tries to drag you through a KonMari or KonMcKinsey exercise, be ready to explain, as patiently as you can, that your organization is a mechanism constructed of interconnected components, not a bag of assets.

And while it’s entirely valid to ask if each component is performing as it should, it’s entirely invalid to ask if it’s contributing enough value to be worth keeping.

It is, if you like, like asking how my garbage cans contribute to my income.

On hearing the question, it will be so, so tempting to point out that the asker isn’t sparking joy in my life.