Interface Grief: Is It Agile, or Just Bad Software Engineering?
I’m a fan of agile principles. As a gray-haired former developer, there are agile software development practices that are clearly superior to some of the practices of more traditional methods.
The ideas of test-driven design, rapid prototyping, and incremental delivery have been around for a while, but putting them under the agile banner seems to give them credibility, and that’s a good thing. Pretending we have perfect information when we don’t doesn’t serve anyone.
At the same time, however, I’ve noticed that “We are agile” is being used to justify some pretty bad software development practices. It’s time we make a distinction between expediency and poor practice.
I had a discouraging conversation with a project manager recently. Her system interacts with several others, consuming data that they send. The systems are being built simultaneously with an externally imposed schedule, so she and her team “got all the liars in one room” and hashed out an interface specification that detailed what information should be sent, what was valid, what was invalid, and how the interface should behave when it received invalid data. The specification probably wasn’t perfect, but it was necessary to assure that the systems were built with an eye toward their future data exchange.
During recent integration testing, it was discovered that the systems integrator building the system that was receiving the information from the interfaces had assumed that the interface specification only applied to the sending systems. Testing revealed that there was no data validation checking on the receiving side of the interface. Invalid data (in this case, string data) was accepted into the receiving database, loading garbage.
When the project manager asked the systems integrator about it, the developers were surprised at her concerns. “We are agile,” they said. “We only build the minimum software necessary to solve the problem. The interface specification is likely to change, and it would be waste to build any data validation.” They seemed genuinely surprised that the project manager would expect the system to be built to defend itself against bad data on the interface.
The PM was amazed, asking me, “In what universe do you ‘trust’ several systems that need to send you information? Doesn’t good software engineering practice apply any more?”
I assured her there was a difference between bad agile and good software engineering practices, but then I ran into another developer who suggested that if the user story didn’t mention what to do with invalid data, the development team should simply accept it. If the user didn’t like the contamination in the database, they could write another story for the backlog to add data validation.
What do you think? Should interface developers defend against bad data coming in on the interface? Should interfaces issue useful error messages when bad data is passed? Are defensible interfaces part of the “minimum viable product,” or are they a luxury?
