App Dev Methodologies – Page 6 – IS Survivor Publishing

Captain Obvious presents: DevOps!

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 differen ce betwee n 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.

When promotions go wrong

As participles go, “excited” is a bit too strong, but “interested” is too limp.

I’m trying to describe my reaction to the email I received from a major air carrier, letting me know I was only a couple of hundred miles short of a first-class round trip ticket to anywhere in the United States. And if I had no immediate travel plans that would take me over the top, I could buy enough miles to cover the spread.

The minimum miles purchase was 2,000 for $59. Not too bad, so I clicked where I needed to click and arrived at the checkout page, which informed me that in addition to the sixty buck price tag, I’d also have to pay $35 in administrative fees.

My wife used to shop at Herberger’s. No longer, because Herberger’s is no more. One reason, we’re convinced, is that we weren’t the only customers who, attracted to the store and website by the many discount coupons they sent us, were annoyed to find that the coupon we held at any given shopping moment could not be used to buy the merchandise we had in hand.

The terms and conditions associated with Herberger’s coupons put your average end-user license agreement to shame.

Which leads to this conclusion, which in turn will lead to the point of this week’s essay: When it comes to structuring any sort of promotion, keep stupid out of it, and empathy for customers in it.

In the case of my first class ticket I can imagine the discussions that led to the $35 admin fee: “Deal momentum” would carry enough customers through that the net revenue gain outweighed the net reduction in total sales volume.

The math probably works. But the psychology doesn’t. All things being equal, the next time I travel I’ll do my best to avoid the airline in question. It’s an entirely predictable outcome, which would have been avoided through the simple expedient of concealing the $35 admin fee … an utterly preposterous number … within the purchase price, just as e-tailers that offer free shipping do.

Which gets us to the point, which is software quality assurance.

No, really.

Increasingly, as part of Digital this and Digital that, businesses are paying far more attention to the customer experience than they used to. As part of this effort, they’re creating mechanisms to understand how customers feel about their interactions with the company.

For telephone callers, it’s standard practice for companies to record calls so as to measure how well their call center staff are handling customer requests and complaints. Web and mobile apps are tougher, but methods for evaluating the customer experience in these environments are rapidly increasing in accuracy and sophistication.

It’s what internal IT would call UAT — user acceptance testing, which, done well, includes end-user suggestions as to how to improve overall usability.

Paying attention to the (real, paying) customer experience on the web and through mobile apps is admirable. I’m in favor of it.

What I suspect receives too little attention, though, is that unlike internal applications, the web and mobile customer experience includes more than layout, design, and functionality.

It also includes matters of more substance, such as the $35 admin fee I’m griping about here, coupons that are (or, in the case of Herberger’s, weren’t) redeemable on e-commerce websites and mobile apps, and, for a third example, requiring shoppers to establish userid’s and passwords before being allowed to buy merchandise.

Those who think in terms of organizational charts are likely to divide aesthetics, functionality, and substance into separate testing regimes. As with so many other forms of business dysfunction, this misguided use of the org chart is a likely step on the path to, if not perdition, at least suboptimalism.

This is because unlike everyone inside your company, for whom the org chart might be sacrosanct, Real Paying Customers don’t care an infinitesimal fig about who reports to whom or how responsibilities are divvied up.

They (which turns into “we” when you and I go home and shop for something) just find all of the above annoying.

Annoying, that is, is for Real Paying Customers a collective gerund, not a decomposable one. Which in turn means that customer experience testing should be collective as well.

KJR’s readers are increasingly being pulled into Digital initiatives of one sort or another. If you’re among them, promote this thought process:

The customer experience is holistic. We have to pretend we are, too.