How many times have you been annoyed by a business partner who tells you exactly how something should be done. Let’s say you’re building a new application and it needs data from a third party. The third party provider has a web service you can call to get a realtime result. However, another application in your organization is already getting that data periodically as well. The business person begins to question your design (and the associated cost of a new call to the webservice) when wouldn’t it be better just to take a nightly feed from the other system and load it? For oh so many reasons, we know this isn’t the right thing to do. The data is likely outdated since it’s now 24 hours behind the realtime version. It ties two unrelated systems, who happen to need similar data, together. Now if the old system changes, you’ll have to modify and retest this new system as well.
If, as developers, we were purists about doing the right thing, it’d be a defensible stance. But how often have we kludged something together ourselves? Take for instance, data we need about our organization. It might come from a Project-and-Portfolio Management tool. Perhaps we want to look at data by “team,” but for whatever reason the team data isn’t available in the tool. Do we try and do the right thing and fix it? Not usually. Just the other day I encountered a data extract, then joined via Microsoft Excel and a vlookup() to a list of people which mapped them to a team. Why was the team data not in the tool? That would’ve been difficult, but the right thing to do. Now, instead of a clear single system of record for team membership, both the PPM tool’s org structure and this one-off would have to be maintained. And while we are often hesitant to make compromises about the stuff we build for the real customers, we will accept horrid messes that create work for ourselves. Why should we be unwilling to have messy solutions imposed on us but willing to impose them on ourselves?
I don’t think we can hold others to higher standards than we are willing to hold ourselves as developers. Don’t create your own messes.