Skip to main content

To improve the quality and maintainability of applications, Thinkwise should provide a project-level option to make all description fields mandatory (tables, columns, domains, references, datamodel diagrams, tasks, etc.). (This means it will be an optional feature you can enable as a project team).

This ensures that developers think about why they are creating something and provide proper documentation during development. To prevent abuse, the feature should also support validation rules so that meaningless inputs (like just entering "." or "test") are not accepted.

With this in place, descriptions become a real part of the development process, improving collaboration, knowledge sharing, and long-term maintainability of projects.

While I agree the SF could be improved on the documentation subject, I seriously doubt making all descriptions mandatory is the best way forward for any project. There are so many things that are clear just by the name, having to fill in descriptions for everything doesn’t add value and makes it even harder to spot important remarks. 

I would try to find a solution in (mandatory) descriptions of a higher level; a group of objects that a developer changed with the same goal (f.e. a user story). Maybe this could be combined with Possibility to review more than just code | Thinkwise Community so different objects/changes in a model could be combined and linked to with a description and be reviewed as a whole.

I'd like to add a small nuance to this idea.

I do believe that making certain descriptions mandatory can help clarify the purpose behind what’s being built. It encourages developers to think more intentionally and improves documentation quality.

That said, I agree with Peter—requiring descriptions for every single element, like each column, could become excessive and reduce usability. It might lead to filler content rather than meaningful documentation.

A more balanced approach could be to make descriptions mandatory for key components that carry architectural or functional significance, such as:

  • Tables
  • Indexes
  • Control procedures
  • Templates
  • Dynamic models

This way, we promote thoughtful documentation where it matters most, without overwhelming developers with unnecessary requirements.

New→Open
Terms & ConditionsCookie settings