Development is not only about the coding!
We’ve build 30 image galleries for only 20 clients in the past. Essentially they are all the same though. Wouldn’t it be far more efficient if we build only one gallery and use it for all our clients?
At first glance the above statement seems feasible. Every line of code needs to be written and maintained. Limiting this to only one gallery would reduce the implementation efforts as well as maintenance freeing time and resources for more thrilling stuff.
However by only focussing on the coding part of a feature you ignore quite a bit of the overall process.
Every feature was conceived before. In this case by 20 different clients. All had their current website design, target group and competitors in mind and all of them came to slightly different definitions of a gallery some of them even came up with more than one. If all of those ideas would have to be answered with only one image gallery it would probably not fit everyone equally well as there were reasons for coming up with 30 galleries instead of just one.
Of course you could argue that having 20 people thinking up galleries itself should be avoided and should be streamlines to a single conception process. You still have 20 clients though who know their website design, target audience and competitors best. You really need them to support this process and they will only do if they can bring themselves in in one way or another. So there has to be a broad discussion.
Unfortunately all 20 clients will not come up with a new feature idea at the same time as they have individual priorities. So you either have to discuss with only a few of them who will define the feature for everybody still to come or you will have to discuss it with all even if they are not interested yet. In the end you will find a compromise that belies expectations.
And the conception process will get a whole lot bigger too.
You will have clients that don’t need a feature now who don’t take part in the discussion only to be confronted with a solution later that might not fit. You will have clients that join the discussion for they know they will need this feature at some point who will have to bend their schedules to discuss something they would’t normally focus on at the moment. And you will have one client who desperately needs the feature now who is utterly frustrated by loosing so much time over discussions with only half interested others.
And I didn’t even go into looking at the maintenance here. How much of your maintenance efforts would you expect to be bugs, compatibility or security issues? Wouldn’t you say that 90% of all maintenance costs are the result of clients changing their mind about something?
Again they will probably have good reasons for it and they will come to different conclusions. So the discussions will have to go on and so does the frustration. Highly paid (probably) people will spend hour after hour for each feature discussion the pros and cons of many details.
Implementing 30 galleries seems a much easier option.
If you manage to reuse and maybe even centralize code within the development process whenever you get an opportunity to and the conception process is not affected by it: go for it!