Once upon a time, there was an IT manager who needed an internal application that would insert data into a table (based on some business logic), and he told his subordinate developer to develop a program that would do so. The developer consented, and after a few days, the developer informed the manager that the program was complete and ready for testing on their QA system. In order to provide the developer with some actual test data, the manager attempted to pull down some data from their QA table…but surprisingly, all the data was now gone. “What happened to the data in the table on QA?” the manager asked. “Oh, I prepared the table by truncating it,” replied the developer. “Now’s it’s ready for data to be inserted. Just give me some data from the production table, and we’re good to go.” Stoically (but showing restraint), the manager said through gritted teeth, “There is no production table yet. That was our only copy of the data.”
Even though it describes more of a breakdown in general communication than in language, it’s an example of what can happen when managers and developers aren’t on the same page. (And, amusingly, it’s a true story.) Even with a manager who is well-versed in technology and with a developer who has social skills beyond a troglodyte, these kinds of mishaps can still occur. After all, even with terminology established during the design phase, the scope and details of a project can fluctuate, resulting in changes of the terminology repeatedly over the duration of the work. Documentation and contemporary methodologies (like Agile) help prevent such mishaps in software development, but like everything else, they are tools which are as effective as those who wield them. Of course, I would never disparage such useful tools; they have more than proved their worth through the years. However, none of these tools possess one important aspect of learning and understanding: interaction.
In most cases, passive learning is not as effective as those cases where the student “gets their hands dirty”. Numerous examples of gamification show how understanding can be enhanced once the learning experience becomes more engaging and, in some cases, more immersive. Since a software project is implemented by developers, the manager’s understanding of their implementation is seen through a lens provided by them, and consequently, it is a developer’s responsibility (and benefit) to craft such a portal with care. With a modest degree of effort and investment, exposed metadata can serve as a virtual console for managers, allowing them to gain some degree of intimacy with an application’s inner workings. Plus, in doing so, the developer gains a certain degree of freedom in the process. In the next post, I’ll delve further into how metadata can make this possible.