An interactive product, whether it is a website or mobile app, is built to meet a set of needs – the general goal of an interactive project is to design and build a solution to meet those needs at a minimized cost. And the engineer depends on a solid understanding of those needs when choosing the materials.
Changing needs is a reality of software development – there are good reasons for the requirements and design of a software system to change during the lifetime of a software system. Business needs change, the market changes, aesthetic tastes change. Costs of materials (platforms, services) fluctuate. New information is always accumulating. The scope of these changes will range from trivial (copy changes, image updates, etc.) to fundamental/catastrophic (company or product fails, user base is 100x expected, etc.).
While many changes are detected early in the scope of a project (at a minimal cost), some will be detected late (creating ripples in the system and requiring more costly changes), and changes do not cease after a product is deployed.
I work primarily in iOS; one of the characteristics of which is that code cannot (generally) be pushed live without a review process by Apple that takes (assuming all goes well) a week or more. And although there is a fairly smooth update process (users get notified that there is an update as soon as it is available), the users are often perfectly capable of ignoring those updates.
Fortunately, there are other ways to deal with these changes – assuming they were in some way anticipated. The heart of an application is responding to variable input, and configuration of the application is a specialized form of input that can save the day when business needs change after an application is deployed.
An iOS app can be configured at the user level using in-app settings, Settings page settings, etcetera – but those settings need to be managed by the end user, and if there is a fundamental change in business needs, this usually will not cut it. We tend to use webservices to deliver a bundle of JSON data, telling the app how to behave/what values to use. This allows us to release an app, then dynamically change its behavior as often and as quickly as we like.
A product from Google (Google Tag Manager) is now making this pattern even easier – for websites and various mobile platforms. It is relatively quick to set up (in iOS, anyway), and should continue to see increasing support. Also, the service is decentralized and administrative rights can be handed over to other stakeholders with minimum hassle.
But accommodating the configurabilty within the app adds significant cost. So the balance should be about the costs of adding configurability vs. the costs of having needs go unmet. And though we can always anticipate that there will be changes, we cannot always anticipate the nature of those changes – sometimes we will end up paying both costs. Not only must we try to detect and understand changes as soon as they happen, we must anticipate the costs of changes we are not yet aware of, and build our solution to minimize the ultimate cost.
Originally posted December 4th, 2013.