I read the latest version of “How Fibery uses Fibery” and thought it was interesting that they have a database specifically for DevTasks (any task that doesn’t add value to the end user)
I’m wondering how others think about the distinction between generic (Project, task) and granular databases (Bugs, DevTasks, Test tasks)
Generic is the most straightforward to setup but it also feels like it gets messy as you add more contextual fields. For example some of my tasks are really bugs, in order to give more context to the bug I now have to add a field for something like affected area.
Maybe the better question is how far do you push the generic approach before it’s worth it to switch to more specific databases?
We have not taken a purist approach to the dilemma and thus have a mix of granular entities (e.g. Task and Build Task, Client Org and Partner Org) but also some generic ones (Meeting, Person) with loads of partially relevant fields.
I would really want to have inheritance across the entities, as that would allow for common fields with granular extensions:
We plan to roll out improvements to entity view in the course of this year, which may help with situations where a single database has a number of fields which are not applicable in all circumstances. In other words, a Task could be views through a ‘Development task’ lens, a ‘Marketing task’ lens, even though all the Task the entities live in the same db.
Ahh that is super helpful. This feels like it fits more with of a bottom-up approach where the necessary fields emerge through actual usage vs. trying to plan the perfect database/fields top-down