In the book Righting Software, Juval Lowy describes Contract Design Metrics. Contract Design Metrics give software designers guidelines when designing contracts/interfaces. The book goes on to describes that there is an optimal range for the number of method on a contract:
- Too large makes them less reusable
- Too small: although more reusable, when they are too granular it takes assembling them back together more work
We have run analysis across several of our projects, all projects are running in production.
Info
We gathered all methods on all contracts and captured the following information: service name, service type, context (although it is not used very often), facet, method, return value, input, the architect, year of the projects (these last two are omitted from the screenshot)
Goal
- Validate the Contract Design Metrics (Righting Software)
- Library of all methods ever designed: aid for DD
- Dashboarding
Conclusions
The metrics align very well with the Contract Design Metrics. Although this could be linked to a confirmation bias in some sense, but for us it shows the metrics are feasible in projects. After close examination of the outliers we see that they should have been split up into multiple facets.
Dashboarding: we are still playing around with this view.
Info
Metrics
Dashboard
Be First to Comment