Overconfiguration occurs when a training pipeline exposes more configurable choices and abstraction layers than its realistic use cases require. It sits opposite underconfiguration: instead of making change difficult, it makes the system overly complex. section 10.4
Balance configurability by asking which parts of the pipeline are genuinely likely to change:
- Make datasets configurable because updates are practically certain. section 10.4
- Avoid exposing every model or training detail when its likelihood of change is low; activation functions are given as an example. section 10.4
- Test changes to catch regression bugs, accelerate iteration, and reveal whether the configuration design is balanced. section 10.7
Listing 10.1 Multilevel hierarchy of subcodings
def train():
...
batch_size = 32
...
learning_rate = 3e-4
...
model.train(data, batch_size, loss_fn)
...
^ example of underconfigured code: things are too rigid
class Config(BaseConfig):
def __init__(self):
self.data_config = DataConfig()
self.model_config = ModelConfig()
self.training_config = TrainingConfig()
self.inference_config = InferenceConfig()
self.environment_config = EnvironmentConfig()
class DataConfig(BaseConfig):
def __init__(self):
self.train_data_config = TrainDataConfig()
self.validation_data_config = ValidationDataConfig()
self.test_data_config = TestDataConfig()
config = Config(
data_config=DataConfig(
train_data_config=TrainDataConfig(
...
),
validation_data_config=ValidationDataConfig(
...
),
test_data_config=TestDataConfig(
...
),
),
...
)
Compare rigid hardcoded settings with a multilevel configuration hierarchy whose nested data, model, training, inference, and environment objects can obscure how the pipeline is controlled. section 10.4
