Oh this is such a hard path to tread, and again the same time hard to know without hindsight what the right path is.
I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons.
In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it with something designed for the one specific context.
But then the context changed, and now heres this bastard-child that's been narrowly designed, and optimised for performance (so hard to maintain or change. ). And the developer is somwhere else.
But equally I've spent a career writing the "new standard solution", which of course started out as an alternative to "the standard solution". And in our context that -has- made a huge difference. So it eould by hypocritical if me to say "stay inside the box".
If you do need to get outside the box, I would give some advice though.
A) documentation. Nobody likes doing this, but this is the most important part. If it's not documented properly, it doesn't exist. And just the act of documentation will show you where the design is deficient.
B) write your code as clean as you can. Make it easy to follow. Make it easy to read. Try not yo be clever and where you are clever don't skimp on the comments. You'll thank yourself for this later.
C) as much as possible try and build for the general case, not the one in front of you. The more useful this vote is the more it'll be used. The more it's used, the easier it is to identify flaws.
In summary - stay on the main road. But if you do need to forge your own path, make sure it's done properly, not some single lane gravel dirt thing.
At the end of the day, I do agree with you. My point wasn’t against the developers who acted like this and if they were right or wrong to do so. My point was about the fact that the knowledge barrier between developers ("R&D") and the upper management is frequently so tight that nobody is ever questioning those choices because let aside the "story points" the damn thing is costing, nobody understands what this is about and if it is necessary or not.
However, that’s just my personal experience, it’s possible that I’ve only seen the wrong kind of companies.
I come across lots of situations, with legitimately bright developers, who have replaced a standard subsystem either a home-grown one, usually for performance reasons.
In that moment in time, in that context, the general solution was less performant or had an ugly bug, or whatever, so they replaced it with something designed for the one specific context.
But then the context changed, and now heres this bastard-child that's been narrowly designed, and optimised for performance (so hard to maintain or change. ). And the developer is somwhere else.
But equally I've spent a career writing the "new standard solution", which of course started out as an alternative to "the standard solution". And in our context that -has- made a huge difference. So it eould by hypocritical if me to say "stay inside the box".
If you do need to get outside the box, I would give some advice though.
A) documentation. Nobody likes doing this, but this is the most important part. If it's not documented properly, it doesn't exist. And just the act of documentation will show you where the design is deficient.
B) write your code as clean as you can. Make it easy to follow. Make it easy to read. Try not yo be clever and where you are clever don't skimp on the comments. You'll thank yourself for this later.
C) as much as possible try and build for the general case, not the one in front of you. The more useful this vote is the more it'll be used. The more it's used, the easier it is to identify flaws.
In summary - stay on the main road. But if you do need to forge your own path, make sure it's done properly, not some single lane gravel dirt thing.