Before I begin to go into further detail, I should quickly mention that there are certain expectations of both manager and developer, in order for this arrangement to be successful. Yes, it seems that “unconditional” isn’t exactly a good word for the work environment. In this case, though, it’s not too long of a list, so it’s nothing to worry about. First, the manager has to be interested in engaging with his/her developers. Sadly, some managers are not fond of collaborating with their staff, with a preference for delegation without discussion. (On the other side of that coin, I hope to never encounter and engage with them.) Two, the manager should have some degree of technical proficiency or interest. Even the simple possession of some SQL skills can go a long way. Three, the developer must have a certain level of maturity, especially when it comes to possessing patience and empathy.
If those simple prerequisites are met, then this collaboration is off to a good start. Now, we can actually talk about the matter at hand: metadata. In the case of most projects, the developers are punching their keyboards before the ink is dry on the design documentation (or, in some cases, before the ink is even applied), and in many of those cases, the metadata does not usually get much focus in meetings. In order to be more illustrative with this point, let me use a specific example that is very close to home. Let’s say that a manager and his team of developers were creating a new business application that ran as a server/service. During the design phase, it’s not unusual for the metadata to be glossed over. Often, the developers will read the design documents and interpret what should be metadata. Then, they will dump those metadata properties and values inside a configuration file for the application, with the intent that the values will be overwritten by a deployment platform (Jenkins, Octopus, etc.) someday.
However, metadata does not have to be dismissed with such a cavalier disposition. Instead, why not take a moment to discuss what will be designated as metadata and why it was chosen. During the design of a software project, it’s beneficial to look for potential improvements from a number of different perspectives; in the case of a business application, there can be many factors to consider when making decisions (scalability, flexibility for expanded scope, usability, etc.). By looking at the project from the perspective of its metadata, it can provide you with additional insight on how to leverage your project even further. What if certain values in the metadata could imply other conditional functionality? What if the metadata could be organized in such a way as to determine business logic? What if certain metadata was established so that the code would rarely ever need to be altered and so that more power was placed in the hands of managers? At the dawn of a new business system/application here at Barnes & Noble, we asked those questions during the nascent stage of its design. We asked many interesting questions, and from them, we found some surprising answers. In the next post, I’ll talk more about our specific situation and how we came to grok on the topic of metadata.