Ideas for how to split a “settings” feature

Some ideas for how to split functionality for managing software settings into small, valuable, pieces that can be developed, tested and deployed incrementally.

Basic Settings

1. No Customizability
2. Compile-time Options

Environment-based Settings

1. Environment Variables
2. Command-line Arguments

File-based Settings

1. Hard-coded Defaults
2. Key-value pair text files
3. Structured Text Files (JSON, YAML, XML)

File + UI Settings

1. Settings displayed in UI: Text files editable, settings visible in UI.
2. Restart needed to reflect settings file changes
3. Settings file changes reloaded in real time
4. Some core settings editable in UI, the rest via file

Settings UI

1. Simple UI
2. Advanced UI: E.g. search, validation, tooltips, etc.
3. Role-based UI: Settings visibility based on user roles.
4. Conditional UI Settings: Settings appear or change based on other settings.
5. Searchable UI: User can find a setting through text search

Programmable Settings

1. Settings changeable via API
2. Database-driven Configuration

Settings Portability and Synchronization

1. Manual export/import of settings
2. Settings Profiles: Manage and switch between multiple configurations.
3. Cloud-based Sync: Synchronize settings across installations or devices.

Intelligent Settings

1. Machine Learning-based Suggestions: System suggests settings based on usage patterns.