Editor's Note: I found this in my drafts, dated 2012-01-25. I have opted to retain the content unchanged, merely updating links for ubiquitous HTTPS and replacing broken links as needed. Please enjoy this work of fiction.
The President saw that things took time to implement in code, and involved programmers, testers, and a deployment. As someone who liked to make snap decisions and have the results available immediately, this did not sit well in his heart. Long he meditated, then announced his solution:
Henceforth, the system would be Database-Driven.
Since code was clearly difficult to develop and deploy, with specialized tools that nobody besides the programmers understood, the Business should not be locked away inside code, where—again—the pesky programmers were the only ones who could access and modify it. And when they made mistakes, restoring the operation of the business also depended on them.
Yes, code was downright dangerous. It simply followed that danger must be reduced by using easy-to-change data in place of the potentially-rogue code. The data could be understandable, so it would be able to be changed by more people, more quickly, and bring much-needed flexibility to the business. The best thing about the plan was that coders loved flexibility, always talking about not needing to be bothered with every little change, so there was complete buy-in. Nothing could possibly go wrong.
The decree went out. The code was changed in a particularly long and laborious process. Some changes to the business interrupted the work here and there, and sometimes mistakes were made, followed by the usual scramble to fix them. All the while, the President looked forward to the vision of the shining new system that would end all these problems.
The database-driven version of the core business application launched, after taking just over three times as long as expected to finish. Soon, half of the office was half-trained on handling the data for the new system, and the changes began happening fast and furious. Just like they should be.
It wasn't long before some problems cropped up, though. Two people editing the same data at the same time could cause problems. When the data seemed to be wrong, nobody knew who had changed it. The programmers worked on it, and soon everything was fixed, such that mid-air collisions were prevented, and a "last edit by" field was available. This way, everyone would know for certain who changed the data.
Soon, another problem was evident; there wasn't any history to the changes, so changing one part of a customer could cause the last-edit field to point to someone who had nothing to do with why some other part was incorrect. It was surely another simple fix—to note who edited the data for every single part of it, not the entire customer record.
Something was happening to the programmers, though. This change was met with a round of groans, though they duly started work. The project seemed to be going on as usual, until one of them snapped.
He called a meeting, and babbled about speech impediments and "those who don't understand process are doomed to reimplement it, poorly" or something like that. The President glanced around the room, and saw uncertainty written on the faces of the other programmers. This guy was so far off in geek-land that even his fellows couldn't seem to understand him. But after a few minutes of ranting, he reached a conclusion.
"So our present situation is like what we had before, except with more people making changes, fewer safeguards, and worse instrumentation and tooling. We're trying to fix that by writing a whole IDE and version control ourselves. And we can't do it while also adding in all these unforeseen edge-cases in the rules engine and keeping up with evolving requirements.
"Simply put, unless we treat the data driving the system like code, the business will be a mess forever—because data is code."
No comments:
Post a Comment