Flexibility Cost

One of the toughest challenges in teaching agile development is the YAGNI concept. Traditional development and BDUF teach you "the design is created before coding and testing takes place". In this environment the decision to implement data(base) driven rules must be made early. Unfortunately, this decision is often based on assumptions that turn out to be incorrect.

Currently, I'm working on an application where exactly this has happened. We have a business rule that will vary by state. The analysis done shows that the business rule will be the same for 35 states (thus leaving 15 exceptions). The obvious solution (to us) was to implement a Strategy Pattern.

The only states that currently needed to be implemented were the base case. We put the strategy structure in place in anticipation of the other states so that adding the other states after we were gone would be a very straight forward task for the client developers.

Upon completion, the client architect asked how we handled the task. He was clearly unhappy with our choice. He required that we provide reasons to code the business rule instead of placing it in a database where a business analyst could add new state logic. I'll list our reasons in order of importance.

1. Testability. Putting the business rule in code allows to easily write tests proving that for each state the proper calculation does occur.
2. Maintainability. All logic is contained in a small (strategy) class.
   
3. Performance. Less trips to the database increases performance.
   
4. Process. Currently, the BAs are not restricted to making changes in QA; therefore, they often make changes directly to production database tables. This is clearly a risk.

Not surprisingly, he did not agree, stating:

1. Testability: "You can test the rule coming back from the database as easily as you can test a rule in code." This is clearly untrue because you aren't testing the logic, but instead testing that the expected result of a database is correct. Since the database can be altered in production the tests become far less valuable.
2. Maintainability: "An application that allows BAs to simply make changes to a table is far more maintainable than forcing a developer to make the change." Also wrong. The application is more flexible, but less maintainable. Additionally, when the application breaks in production it's going to be harder for the developers to track down the source of the bug.
   
3. Process: "The current process does not allow production access." This was also untrue because in an earlier conversation it was stated that they needed to have it in a database to "allow for quick changes in production if a mistake had been made." The point that the code should be tested and the mistake should not make it to production had clearly been lost.

Unfortunately, we were forced into the inferior implementation because of the fear of implementing a new state. Will they ever know they were wrong? No, because the new implementation will allow for the (unnecessary) flexibility and the benefits of the correct implementation will never be noticed. Ignorance is bliss, but it comes at a cost.