Java Testing and Design - 1.3 Why Writing High-Quality Software Today Is Hard

In this section, the author offers 5 prime reasons why creating software is difficult:

1. The Myth of Version 2.0 Solidity - this is when people believe that scrapping the 1.0 product and starting from scratch will create a superior product.  A rewrite is a major overhaul and in the author's experience a more moderate approach has proven its worth.  There is more stress to get the rewrite to the same state that the 1.0 is at and there is no "down time" for developers to recharge their batteries.  A smaller, iterative technique allows for constant improvements without the burnout.  
2. Management’s Quest for Grail - this is when management lays down the law and says all projects and all teams shall use methodology X.  The author contends that there are different programming styles which require different degrees of architectural direction: Users, Super Users, Administrators, Script Writers, Procedural Programmers, Object Programmers, Interoperability Programmers and Orchestration Programmers.   A team must select a methodology that matches the ability and style of the team members.  Forcing a team of Script Writers to adopt SCRUM might not be a wise decision.
3. Trying for Homogeneity When Heterogeneity Rules - trying to standardize the entire company on a single platform is not practical because you need to exorcise the "impure" parts of the existing solutions, which never happens in practice.    Solutions were built upon technologies that made sense at the time and provide useful functionality so deal with it.
4. The Language of Bugs - instead of using bug numbers as the vocabulary to describe if a system is working correctly, why not use a test agent that is modeled after a single user?  Choose just one user, understand their goals, and learn what steps they expect to use. Then model a test against the single user. The better understood that individual user’s needs are, the more valuable your test agent will be.
5. The Evil Twin Vice Presidents Problem - this is the scenario where development and test is run by one person and the data center is run by another.  This promotes sniping between the two groups where cooperation would be more productive.  The author recommends providing a common testing framework that is used by development and test to run functional, scalability and performance tests.  The IT guys can leverage that framework to verify the health of the system and provide QoS reports.