| In some situations, we are faced with features whose cost rises sharply. We should take this into account and expect to perform more work up front. We should also try to minimize the cost so that we can gain the benefits of the incremental method. Here are some examples. Externally used, published APIs. Once the APIs are in use, customers will demand backward compatibility or a simple upgrade path. Effort should be spent on keeping the APIs flexible, minimal, and useful. Development teams that aren't colocated. Up-front effort should be spent on partitioning the system to be developed. Databases used by multiple, independent applications. Common abstractions should be used to encapsulate persistence. When applications are released independently, the persistence and model layer should support some level of multiple version support. Software in which release to customers or distribution is expensive. Frequent releases can train the development and production team to perform these tasks as efficiently as possible. Aspects of the application that have an overall effect on all of its parts. Examples are internationalization, scalability, error handling, and so on. Having to make changes that affect all of the software makes refactoring very expensive. Interfaces between different teams, global properties of the system, and software that is distributed to remote customers have a high cost of change. Some areas that are commonly thought to have a high cost may have a surprisingly low cost of change. Except for hard, time-critical software, well-factored code can be changed to meet performance criteria. A few simple and general design techniques can be used up front. Most of the performance-related work can be done only after measurements have been made on the integrated system. A process that integrates and delivers often, combined with performance measurements, is the most effective way of developing well-performing software. Database schema changes for software that is owned by one team. A team can get very good very quickly at dealing with schema or interface changes if all of the software is owned by the team. Version detection, upgrade programs, and encapsulation of version-dependent modules enabled my team to make fundamental changes to the database structure, without any customer noticing it. |
