- Tags
- Article
- Architecture & Design
- Software Development
Suddenly Platypus!
'Responsibility Creep' is often seen in older systems. A component will gain responsibilities over time as new requirements arise. Often these new responsibilities will not be cohesive with the component's original responsibilities.
This creep is especially common in integration oriented components - because of their 'glue' nauture, it's both easy to rationalize and easy to implement the addition of new behavior. So over the course of a decade, tweaks here and there will be added in, gradually changing the nature of the component, until someone new comes into the organization and points out that it's very odd to have a furry animal laying eggs and producing milk. By this time, some of the older features are no longer necessary and their existance can only be explained by the cranky old timer down the hall.By this time, it's generally thought that it's time to re-think and re-implement, but I think it's worth asking: is it inherently wrong for a software component to change its responsibilities over time? After all, the flywheel in my car not only serves as rotating mass to smooth power output, but is also core to the clutch and is engaged by the starter motor. One key difference is, of course, that an auto part is redesigned when it gains new responsibilities - I didn't attack my flywheel with a grinder to cut starter drive gear teeth into it!