Hi all,
I think the interesting chat in today’s meeting about reuse and sharing our builds warrants more discussion so I thought I’d add my 2p here to perhaps kick that off.
Our head of service is very keen on reuse, it was a major selling point of Create for him. However like many of you we’ve struggled with it, and we now shy away from it.
When we’ve installed modules from other teams we’ve usually had to make some quite major modifications to suit our needs, and we have ended up with solutions that are harder to maintain due to building around an existing structure rather than building from the ground up to suit the requirements of the service in question. So all in all the time saving we’d expect from reuse is completely negated.
That’s not due to poor development on either side, it’s just down to a mismatch of requirements. Sometimes a fairly innocuous requirement will have large implications on your design, and if a system is built in part around a requirement you don’t have then it can be a pain to unpick.
So the issue as I see it is that we’re sharing systems we’ve built, rather than building systems to share.
I’m interested in exploring if we can we abstract some of our commonly used systems down to easily extensible and configurable frameworks, whereby we identify the core shared requirements and architect the build in such a way that anyone can take it and add their bespoke functionality without needing to worry about removing anything.
You could perhaps take that a step further by making small modules of that bespoke functionality to share with others who might need it. So instead of installing a complete Garden Waste solution you might download the Garden Waste framework alongside a Garden Waste subscription module and an Alloy integration module etc.
I appreciate that this might be easier said than done, it would be great to hear your thoughts!
Russ