Why Media Companies Should Pay Attention to Software Development/Operations Integration

      No Comments on Why Media Companies Should Pay Attention to Software Development/Operations Integration

Many if not most media companies invest relatively little in software development. But those that do have been grabbing the attention of an increasing number of readers, subscribers, advertisers, and investors. What to do if software is not in your DNA, and why do you want to do something about it in the first place?

Adopting new tools and workflows is work, no matter how you slice it, so I will highlight that this is not just about operational quality control or developer productivity – though these are important in their own right – but more importantly about maintaining competitiveness in light of shifting readership expectations and behaviors. Here is the business case for paying attention, and carefully adopting, some of the latest methodologies popular in web development circles. For many organizations this may require a significant cultural shift.

Table of Contents show

Publishers Struggle to Face Mounting Expectations, Shifting Constraints

Just as things get easier on the desktop… Catch this mobile curveball

First, let’s look at the technical environment facing online publishers. These days (circa 2013-15) it is easier in many ways to create websites that work well, thanks to older versions of Internet Explorer finally fading away. Developing interactive user experiences in IE 6-8 was expensive and messy at best, but the market has finally moved on. Working with HTML/CSS/JS on top of today’s browsers is a boon compared to having to resort to countless browser-specific hacks, let alone using Flash for interactivity. It is hard to overstate the impact of web standards that are finally easy to work with and widely supported by the installed base.

On the other hand things have become much more complex because of the explosion of mobile device form factors. These days you cannot develop and test a website with a relatively fixed set of functionality for a fixed resolution. Instead you end up developing not just a responsive design that visually adapts to different resolutions, but also optional functionality depending on the context. Some things don’t make sense on small mobile devices (say, complex data tables and visualizations), and some are only possible on them, such as apps using their embedded camera or GPS.

The bar is raised even higher if you eschew mobile app development and focus all your efforts on the web, where one code base attempts to address all devices. As websites offer increasingly sophisticated experiences, that extra functionality comes in tension with performance requirements raised by mobile use. So you cannot just pile up the latest trendy Jquery plugins and call it a day.

The alternative is to develop native mobile apps for iOS or Android, but I believe this to be a huge waste of time and money for most publishers. Many of the trend-chasing news apps of the day have been unmitigated disasters, crippled by locked-in content (how do I share this?) and poor functionality, then buried in busy app marketplaces, these factors leading to little sustained app adoption. Likewise, many badly designed mobile-specific websites have been forced down the throat of users with disastrous effects on their experience, as well as backfiring on publishers (duplicate content leading to poor SEO comes to mind). If your experience as an information consumer is anything like mine, you’ll agree that many firms have found the hard way how *not* to serve new platforms.

This is best summarized by Michael Corleone via the Sopranos: just as you thought you were out (of web development headaches), they pull you back in.

Chase fad, Exhaust resources for underwhelming Results, Rinse and repeat

The result is that many publishers, especially the small/medium trade or local ones, are stuck in a cycle of fad-driven cosmetic “redesigns” every few years, with a few dead-side projects interspersed here and there. These website makeovers typically a) break everything that existed before, with broken URLs and even entire archives being wiped out, and b) are too rigid to accommodate iterative changes, leading to more of the same. Have you noticed how so many hyperlinks that are not even a decade old are already broken? Larger publishers can get away with it for a while if they have a strong offline franchise (typically print), but as corporate decision makers are increasingly digital natives, sooner or later these organizations will have their lunch eaten by more nimble competitors if they don’t adapt their workflow and culture. And even if nobody bothers to come and eat their lunch, audiences will simply disengage.

A pet peeve of mine that illustrates this too well are “digital editions” that mimic what the print magazine looks like, down to the sound of turning pages? Who the hell has time for this? Terrible, terrible idea, no sane business reader who values their time can possibly engage with that type of media. Even venerable media properties can do better than this. But often they burn a considerable amount of time and money shuffling their CMS and site design with little to show for it, then stop investing for the next couple of years, exhausted and disappointed, or worse, self-satisfied in the illusion that they’re now all hip and relevant again.

There Must Be a Better Way

To meet these challenges, the benefits of integration between development and operations are too good to pass, from minimizing manual sources of error, to contributing to a good user experience. Tech-centric companies have been shortening the delay between development and production, and media companies should pay attention.

DevOps: Huh?

Get information flowing between your readers and your product

A focus on agile, iterative development supported by the right dev-to-production processes has allowed new online services to grow at an unprecedented scale. This entails complementary goals of reducing internal friction, putting things in the hands of actual users early and often, all the while maintaining quality. The intent is to move away from big, long projects done in a tunnel away from customer exposure, and work in a more gradual way that keeps building upon itself.

You may hear about “continuous integration / delivery” or the more fashionable “DevOps.” Let’s break that down in a non-technical way. The big, infrequent product release cycle (think a new Microsoft Office every 2 years) is proving to be too slow as it locks in too much value for too long. Websites can be updated on the fly by smaller, more digestible increments. Readers/users see the result of their feedback looping back into your product in a way that contributes to their loyalty with your brand, because they feel they have skin in the game and being invested in what you have to offer is worth it.

In the end, software automation tools have an impact beyond your organization to make its border with the outside world more porous. Internal efficiency turns into external efficacy. But a feedback loop works only if you close it, and do so relatively quickly. If you try to establish more fluid relationships with your readers by asking for their feedback (“we’re listening, we swear!”), but then nothing happens for years, you’re setting yourself for disappointment and failure. They’ve heard that song from countless corporations and politicians already.

Being able to incorporate customer feedback in your online products sounds great, but you need safeguards so that shipping code to production more often doesn’t wreak havoc. At the most basic level (where many respectable companies probably still are!), manually uploading files to production is just too error-prone. With the dread that something might go wrong comes a level of friction that will lead to either frequent breakage, or a very slow development cycle.

When you see a site in the middle of a version transition for weeks at a time, with navigation and search leading to frustrating dead-ends, you know the underlying build process is not up to par. I’ve witnessed this again and again from large publishers as well as some of the biggest corporations. To your customers this screams that you don’t care more loudly than any PR statements that you do. Actions, and mishaps, speak louder than words.

If you’re now convinced that infrequent, monolithic release cycles are no longer good enough, see the links at the bottom of this entry for further discussion on the mix of tools and mindset involved. There’s plenty of food for thought there to foster discussions between business management and the tech team. Yet, before you dive in because I did such a good job convincing you, a caveat.

The limits of continuous everything

The idea of continuous delivery is grounded in efforts to improve industrial processes, with a similar focus on deliver value to customers thanks to feedback loops. Concepts such as Kaizen predate current web development trends by decades, and organizations want to avoid going through the same learning curve just because new names are used to repurpose old concepts. One known major pitfall of having a smooth, ongoing develop/test/ship process is that it makes it easy to stay busy with a stream of minor improvements which may add up to a bunch of quality of life improvements but collectively lack oomph (how many “new” cars feel really better than the previous year’s version?). It’s easy to confuse input and activity with output and impact.

Just like digital marketers should be wary of split testing relatively minor stuff because they can (should we make the Buy button green or blue?), online product managers have to maintain a strong prioritization discipline, and balance the easy stuff that can be delivered on a same-day basis with more meaty and ambitious projects. Moving from a workshop where everything is done in an adhoc way to an automated factory is necessary but not sufficient to deliver more of a better product.

Are you a publisher seeking to develop digital products – including in a more agile way? Are you considering using data and visualization to increase your revenue? Then we should talk!

Resources to Learn More

Leave a Reply

Your email address will not be published. Required fields are marked *