in Coding, Featured

Do people really want their software to update so frequently?

Like some, I spent the recent year-end holidays reconnecting with family and friends over a tin of homemade chocolate chip cookies and non-fat cappuccinos. We laughed. We cried. We debated the merits of Agile deployments and Minimum Viable Product (MVP) delivery.

It began as an innocuous statement: “Drive-thru windows at coffee shops. Call-ahead seating at chain restaurants. Online order pickup at big-box stores. Clearly we’re an impatient society. We know what we want. And even if we don’t, we want it now, anyway.”

This particular meet-up was between myself and a senior programmer with whom I worked fifteen years ago. He was always a better-trained and better-skilled programmer than me, a computer science major with a firm footing in C/C++ and Assembly, whereas my computer information systems degree shifted focus to higher-level programming languages and business classes like accounting, marketing, and economics.

We reminisced about our time as programmers together and jointly landed on a few takeaways:

  • It’s difficult to be a good programmer today; organizations want programmers focused on speed of delivery, not quality
  • The decline of quality programming became more prevalent with the introduction of managed code, particularly Microsoft .NET, as it allowed inexperienced programmers to deliver products to market
  • Availability of quality software further diminished with the introduction of smartphone applications
  • Somewhere between then and now, organizations began touting minimum viable product (MVP) and Agile deployment to mask what could be best described as impatience—usually on the part of the provider who holds the financial benefit
  • Enterprise cloud software developers have not embraced the plug-in model to better support an organization’s appetite for change—mainly because it requires more attention on early application architecture

As I progressed in my career as a programmer within ten-person startup companies during the dot-com era to thousand-employee enterprise organizations, I experienced the disheartening feeling that end-users don’t care about software systems as much as programmers think they do. Consider the origins of the RTFM meme, for example. Clearly people don’t and won’t read the…ahem…manual.

As a previous system administrator for two cloud hosted project portfolio management (PPM) systems, I came to learn that the average end-user learned just enough about the enterprise software to get by in their day-to-day role. And when an end-user did master a feature in the product, it usually changed in some minor way a few weeks later when the developers pushed a new feature or update to an existing feature.

So if end-users won’t read the manual and only make an effort to learn a fraction of the application’s capabilities in order to perform their job, do frequent Agile deployments of hosted software diminish value? In my opinion: yes.

Wearing my change management and system administration hats, I feel deployments of enterprise cloud software are best received and adopted by end-users when limited to once or twice yearly. This ensures the organization can take appropriate measures to evaluate, learn, and understand the new features as well as define and change management and training strategy that’s right for the organization based on the team or function’s current level of maturity in the particular application and/or application processes.

As new enterprise cloud software manufacturers enter the market I believe they can grab a competitive advantage from their peers by focusing early application architecture efforts on developing their software to utilize a plug-in architecture. From there the deployment cadence and new feature adoption can be managed by the customer to better maximize end-user value.