PO: The next task involves implementing an API that retrieves the list of available templates for one of our clients. It's also necessary to specify in the returned list which templates are usable and which are not. We have a boolean in the database indicating whether the template is usable or not.
DEV: A template with all the characteristics of a template but isn't usable? What's the purpose of such a template?
PO: Yes, of course, there are templates that are not usable. Check the database, there's a boolean. And even when you look at the screen during template creation, you'll see a checkbox to specify if it's usable or not.
DEV: But what's the use of a non-usable template?
PO: It's used to group the usable templates.
DEV: Don't you find it strange that we create a template with all the characteristics of a template just to group other templates? And that we put a checkbox to say it's not usable? In that case, what's the point of all the attributes of such a template?
PO: It's pointless. When this boolean is true, the attributes serve no purpose. But viewed like this, we indeed have a problem. In fact, it's not really a template but rather a template family. We didn't think about all this when we implemented this feature, but you're right.
DEV: A template family seems more appropriate, yes. I'll therefore add the notion of a template family in the code, and this notion won't have all the characteristics of a template. This will prevent us from checking this boolean every time on the templates and will make everyone's life easier.
Several functional debts hide within our features every day. To detect them, we need savvy developers who are interested in the product's domain and who challenge the requirements. If developers simply execute what they're asked without understanding or challenging the needs, this kind of debt will spread throughout the application.
#software #Collaboration
