Data Driven Projects

Posted by Rich Crowley in common sense, Design, productivity, Risk, waterfall

From the dawn of programming time, one of the holy grails that programmers have chased is to avoid hard-coding data values into program code if at all possible. Since most significant applications use some form of database management system, software applications can be developed that are extremely flexible because their behaviour can be changed by manipulating the underlying data, rather than program code.

Over the past ten years, I have worked on a ton of projects where application changes requested by business stakeholders involved nothing more than database table changes. Such projects involved changes as diverse as client correspondence changes (ie. letters, statements, etc.), adding multilingual support, product pricing changes and sales force compensation changes.

In most of these cases, the projects followed a traditional waterfall development and PMBOK-based project management approach. However, one of the common struggles I have encountered with such projects (across several clients, different business cultures and development shops) is that these methodologies are geared towards code / logic changes and cause confusion amongst stakeholders with respect to how much documentation is needed if only some data is being updated.

For example, technical documentation such as functional business requirements documents, technical specification documents or testing strategy documents are more difficult to get agreement on between the various stakeholders in such projects. This is because some stakeholders advocate that if you’re only changing application configuration data, you aren’t really changing what the application does or how it does it so you don’t need to test any underlying functionality.

If the code works with existing values of application / config data, it should continue to work with different values since the logic has not changed. These tend to be the less risk averse stakeholders.

Other stakeholders advocate that even though the logic has not changed, data changes could result in application problems anyway. For example, if a document shows the interest rate being charged on a mortgage product on a renewal offer letter, and the rate has increased from 8% to 10%, this simple data change could result in a truncation problem that has been hidden up to this point (ie. if the number of significant digits on the letter allocated to display the rate is one, and the 10% value requires 2 digits, this problem would suddenly appear where it hadn’t before.) Stakeholders in this camp tend to be of the risk-averse variety.

There is no magic solution here but common sense helps as much as anything. I have found that keeping the documentation light around the changes themselves has not caused undue harm or risk and that having a good and thorough review of how to test the potentially affected components, and then keeping the testing on the light side as well once those components have been identified, goes a long way to getting such projects done quickly, efficiently and with minimal risk.