"It is difficult to get a man to understand something when his salary depends on his not understanding it." -Upton Sinclair
When an internal software application reaches critical mass, it can become a self-perpetuating fiefdom that generates work well beyond its natural lifespan. People employed on an application full time have an incentive to continually extend and improve it in any way that keeps the development effort going, whether or not the work is really worth doing. The application becomes their purpose and identify, a fiefdom in which they reside and over which they rule. Once established, such fiefdoms can be hard to recognize and dismantle, so managers must take conscious steps to prevent their formation and speed their dissolution.
Measuring the true value of internal software
When you produce software that's for sale, it is relatively easy to tell if you have a winner. The costs of creating it can be tracked readily, and among the benefits it brings to those who are selling it, revenue is king. Since revenue, like cost, can easily be determined, it is fairly straightforward to compare the money coming in to the money being invested, and thereby establish whether producing the software is worth the effort.
When you produce software for internal use, however, things become less clear. You can still establish what you are paying to produce the software, but instead of revenue, you must balance your production costs against some idea of benefit. The software allows you to do things that you couldn't do before, or to do them better, faster, or cheaper. Quantifying this benefit is of utmost importance when figuring out your return on investment, but it is a very hard thing to do.
Whereas revenue is easy to tie back to a product, it is hard to tie internal improvements back to a single cause, given the multitude of variables that impact internal operations. The benefit that should be ascribed to any single factor will be debatable, and so there will be no way to conclusively determine how much benefit an internal application brings. This means that domain-aware expert judgment is needed to assess the sensibility of continued investment.
Conflict of interest
Who is best equipped to make such domain-aware expert judgments? Surely, the experts are those closest to the effort: the people who work on the application and its concerns every day. However, it is precisely those people who have the largest conflict of interest in making such determinations, as well as a limited ability to consider the opportunity costs of their efforts. The team working on the application benefits from their association with it and may naturally wonder what will become of them if further development isn't needed. Both comfort and cognitive dissonance make it difficult for them to consider that the object of their earnest labors may not be worth supporting further, and since they are dedicated to that single application, they likely lack the perspective to appreciate the virtues of other areas in which their time would be better spent.
This dynamic applies not only to the technical personnel working on the application, but also to product owners, business analysts, and anybody else who lives in the fiefdom. Moreover, since the majority of the development investment will come from the technical side, it is unlikely that a call to stop development will come from the business side, unless the business side has higher-priority items for the technical team to attack. It is easy for me to rationalize continued development that benefits me and that is financed by somebody else's budget.
Considering the above, application teams will usually be ardent supporters of continued development, and because of their expertise in the area addressed by the application, it can be hard to argue with their conclusions. When someone proposes halting or pausing the application, the application team can marshal a formidable array of justifications, both quantitative and subjective, in favor of continued development. Somebody who doesn't live in their world will have to expend great effort to separate dispassionate assessment from defensible exaggeration and to counter speculative value judgments with reliable data.
How to break down the fiefdoms
Application fiefdoms perpetuate a wasteful, self-reinforcing cycle. The longer a team works on a product, the more entrenched and intractable they are likely to become in opposition to its discontinuance. As such, management must develop reliable ways of identifying and disrupting application fiefdoms. The following four methods are helpful options to explore.
1. Use a chargeback model. Using chargebacks to finance internal application development changes the economics of internal software development to resemble those governing external software development. When business units must finance the construction of internal applications, they will be more circumspect about opportunity costs and more conservative about assessing returns on the development investment. However, few organizations use a chargeback model for internal development, and introducing such a model would be a sweeping change. Depending on your situation, other options may be more practical.
2. Implement formal portfolio management. A formal portfolio management process for internal applications will establish clear project selection and review criteria. Initially, an application needs to demonstrate that it can produce meaningful returns that outweigh those possible with other work. To endure, the application needs to survive regular reviews in which it demonstrates its continued worthiness. A formal portfolio management process elevates decisions about development efforts above ad hoc decisions into a consistent, disciplined process in which project selection criteria are public and during which the relative merits of different initiatives can be openly debated and compared. While formal portfolio management is advisable, it requires a broad organizational commitment to be effective.
3. Regular resource rotations. If you routinely rotate personnel from one product to another, those employees will identify with the broader organization instead of a specific system and therefore will be less likely to build application fiefdoms. What is lost in project-level continuity may be compensated for through the benefits of cross training and broader organizational awareness. By staggering the timing of the rotations and varying durations by role (e.g., an architect might stay in each assignment longer than a front-end developer), managers can mitigate the negative impacts of personnel changes.
4. Planned development hiatuses: If none of the above prove workable, it may be useful to establish an organizational policy that puts the development of applications on pause at regular intervals. For example, six months of development might be followed by a two-month pause, or a year of development may be followed by an idle quarter. Such pauses break the inertia of ongoing efforts and ensure that development will only begin again if there is sufficient demand to overcome the inertia of being stopped. Because of its arbitrary character, this method should be used sparingly and only until the organization is able to build the kind of culture that would make it unnecessary.
Among internal software projects, application fiefdoms are common but rarely discussed. Managers must be on the lookout for these fiefdoms and should consider applying one or more of the techniques above if it seems as though some development efforts are driven more by momentum than by demand.
While these steps should work for most people, I'm interested to hear about how others have successfully dealt with application fiefdoms. I look forward to hearing your thoughts and suggestions.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
