the new customer and business demands. Increased test and deployment automation for repeatable and specific activities in software delivery provides the structure necessary to allow the software to evolve for these new demands.
- Lower the threshold of pain
At a workshop in Grand Rapids, Michigan on Technical Debt that I participated in, Matt Heusser proposed that technical debt could be an outcome of individual developers not having to deal with consequences of their actions. The decisions that we make each day in developing software lead to technical debt due to this "moral hazard".
Moral Hazard is the prospect that a party insulated from risk may behave differently from the way it would behave if it were fully exposed to the risk.
This does not mean that team members act in a malicious or dishonest way. It means that if individuals are insulated from the long-term effects of a decision then we will not take as much care in the short-term. Matt's example was that a person may take a shortcut in developing a feature since they are not going to be working on the code 1 year from now when it must be modified to support a new feature.
Immediately following Matt's discussion on moral hazard, Chet Hendrickson pointed out that a good way to minimize the moral hazard problem is by "lowering the threshold of pain". For instance, Chet brought up how many people approach doing their taxes in the United States. They could incrementally update their taxes 2 hours each month. Instead many of us wait until 2 weeks prior to the deadline to get our tax forms completed. We push to complete our taxes by the deadline because the potential headache of tax evasion is strong enough that it crosses a threshold of pain. The approaching threshold causes us to act because the pain is something we do not wish to feel.
Lowering the threshold of pain involves decreasing the duration to get feedback at all levels of software development. Automate programmer tests and execute them in each developer environment. Provide access to automated integration test execution to entire team and stakeholders. Reduce logging of defects on functionality getting worked on in current iteration and increase communication between those that find defects and those that can fix them. The ultimate goal of lowering the threshold of pain is to attain "push-button release". This will give flexibility to the business so they can decide to release whenever it makes the most sense and optimizes their return on investment.
Evolve Tools and Infrastructure Continually
Ignoring the potential for incremental improvements in existing software assets leads to the assets becoming liabilities. Maintenance efforts in most organizations lack budget and necessary attention. The International Organization for Standardization (ISO) standardizes on four basic categories of software maintenance in ISO/IEC 14764:
- Corrective maintenance - Reactive modification of a software product performed after delivery to correct discovered problems
- Adaptive maintenance - Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment
- Perfective maintenance - Modification of a software product after delivery to improve performance or maintainability
- Preventive maintenance - Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults
Most maintenance efforts seek to prolong the life of the system rather than increase its maintainability. Maintenance efforts tend to be reactive to end user requests while business evolves and the technology decays.
To prevent this, attention must be given to all four categories of software maintenance. Budgets for software projects frequently ignore