You Have to Prioritize Between Build and Maintain

March 29, 2016


Have you experienced the following situation?  You use a software application, you like it, and the software company comes out with a new release.  The software gets better, and you like it even more.  The company comes out with another release, it is even better, and now you love it.  Perfection!  The company then comes out with another software release and that one “thing” that you used to do so easily was moved in the user interface and, well, you’ll figure it out but it doesn’t seem quite as great as it was.  The company comes out with another software release and now you cannot even locate the function that you originally used all of the time so easily. Now, you want to get rid of it and switch to something else.  Does this sound familiar?  It happened to me with Apple’s iTunes.  I can’t stand using it now, and can’t build playlists nearly as easily as I used to.  Why is this?

Often, with an IT application or system there is a point of diminishing returns where the added features and functionality not only overshoot the needs of the user base, but may in fact start moving everyone backwards.  What were good ideas are supplanted with new ones simply because the “builders” cannot stop themselves from building.

It is important in IT to not only separate the reasons for “new development” vs. “system maintenance”, but to overtly and decisively plan for new development on a system to transition into maintenance mode for sustained periods of time. What is the “ideal state” where the software operates to its optimal level at which point you begin to back off of the development and transition efforts to training, bug fixes and refinements, system uptime, etc? That prioritization between building new features and optimizing the current ones can be a challenge for many organizations!

There are some comparable situations in other industries that I find instructive.  For example, we work with many transit agencies (subway systems, etc).  One of the mantras of the transit systems like Washington Metro, BART, New York MTA and others is that the people who build the system shouldn’t be the same as those who operate the system.  For example, in Washington DC, the current Metro system was built in the 1960s and 1970s and it required engineers who knew about the design of subway stations, ingress and egress, tunnels, securing rights of way, developing network topologies for running subway cars, powering the system, fare systems, etc.  It was a major effort and had major expenses associated with it.  The engineering skillsets that enabled a transit system to be built out were varied and complex, and at the same time they turned out to be very different than the skillsets needed to manage the system.  The “operate the metro” skillsets include knowing how to manage assets and maintenance schedules, developing processes for ensuring rail car safety, training of train engineers and operators, scheduling and repair of elevators and escalators, running on-time analysis – in short, the on-going investments required to ensure a safe passenger experience at high volume levels to recoup costs.

Similarly, I visited the United Airlines maintenance center in San Francisco several years ago.  The maintenance professionals told us that while the manufacturers certainly built a great plane, nobody knew how to keep them in the air better than United.  Their maintenance facilities are second to none, and have many creative capabilities for repair and restoration of airplanes at the most judicious cost-levels possible while maintaining world-class levels of safety.

While we have seen complex systems like transit or air carrier networks being operated by organizations who understand the difference between “build vs operate” and have transitioned to it, in IT and software we still focus primarily just on the “build it” side, called development.  When new IT products are built, oftentimes the people who designed and developed them continued to roll out more and more design, more development, more testing, more features, more complexity.  They have a “build-it” mentality and they continued to – you guessed it – build it.

Transit systems learned this the hard way by having the “builders” also trying to operate, creating safety issues across the board; with air carriers they have learned to collaborate with the aerospace companies to build a great product, but then the carrier takes it forward operationally to maintain and get the most value out of the assets and air carriers provide one of the safest travel experiences in the world.  Software needs to know when to move from the forward momentum of development to the space where the users know the system, they really gain in productivity, and the product provider focuses on training and maintenance to supercharge the use.

In order to approach IT software development in this way, what is needed is “planned operationalization,” where the tough prioritization decisions are made and the “build-it” team is moved off of the product when the time is right and it is handed to customer-service oriented people who then operationalize and support it for the customer base, focusing on usability and experience – supported by a minimal level of development to serve their needs.  The concept of usability should be broadened from just “is this feature usable” to an overall global perspective of how usable the application is for the target audience.  You may build individual features that each, in of themselves, are usable on a standalone basis, but when put together they overwhelm the user experience and push it into the realm of “unusability”.

The “ideal” product has both a particular design and also a temporal aspect which dictates how long it will be in use as a static product before it is obsoleted to new technologies.  Now, can someone call Apple and explain this to them?