Well if during the development I think about something that may come out later (but it's not business approved), I forget about it. Let say I'm creating a comment section for a blog. If I only have 10 comments/day, I'm not gonna create a very complicated administration panel just because "it's going to scale". That's the idea.
But, I do agree with you: it's hard to write code for the present!!
How to avoid writing your own "framework code" (or "core components", as you call them)?
Don't get me wrong, it's ok to have your custom component. I was working on an educational product. We made our own calendar/timetable... And I still support this.
However, I think creating our own Tab/Panel/Popup component was a waste of time.
If you feel you're reinventing the wheel, just take an OSS (or a paid) component library.
How to do all that and still avoid all that ugly copy&paste, that has become increasingly common in frontend code? Or is copy, paste and adapt a good way of doing things now?
Hmmm good question. I'm not completely against code duplication. As someone told me once: "duplication is far cheaper than the wrong abstraction". Duplicating code x2 or maybe 3 times is ok. But at the 3rd time, a dark pattern is emerging and, it's time to do something!
When we planned our sprint we dedicated 10-20% for tech debt reduction. So we're sure debt stay "under control".
"I'm not gonna create a very complicated administration panel"
This sounds more like feature creep or miscommunication within the team, no?
"I think creating our own Tab/Panel/Popup component was a waste of time"
Sure, if a library already does the job (and it is sufficiently flexible and/or has an active developer team), it's a good starting point. I find, I often end up writing light-weight wrappers on top of most libraries just to remove a lot of the boilerplate. This way, 80% of the library's usage (hopefully) ends up streamlined toward one or two specific approaches, rather than having everyone on the team trying things out and then ending up with a mess of mis-used features and squares squeezed into circular openings. I guess, this approach might apply to teams mostly consisting of Juniors who would appreciate the additional guidance, not necessarily to more experienced dev teams.
"Duplicating code x2 or maybe 3 times is ok. But at the 3rd time..."
"we dedicated 10-20% for tech debt reduction"
Good ideas and sounds like numbers to play around with. I will certainly incorporate that into future planning!
All in all, you are bringing up great stuff! Thanks for the quick forth-and-back.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey @Domi thanks!
Well if during the development I think about something that may come out later (but it's not business approved), I forget about it. Let say I'm creating a comment section for a blog. If I only have 10 comments/day, I'm not gonna create a very complicated administration panel just because "it's going to scale". That's the idea.
But, I do agree with you: it's hard to write code for the present!!
Don't get me wrong, it's ok to have your custom component. I was working on an educational product. We made our own calendar/timetable... And I still support this.
However, I think creating our own Tab/Panel/Popup component was a waste of time.
If you feel you're reinventing the wheel, just take an OSS (or a paid) component library.
Hmmm good question. I'm not completely against code duplication. As someone told me once: "duplication is far cheaper than the wrong abstraction". Duplicating code x2 or maybe 3 times is ok. But at the 3rd time, a dark pattern is emerging and, it's time to do something!
When we planned our sprint we dedicated 10-20% for tech debt reduction. So we're sure debt stay "under control".
Hope I answer your questions :)
Thanks for the reply!
This sounds more like feature creep or miscommunication within the team, no?
Sure, if a library already does the job (and it is sufficiently flexible and/or has an active developer team), it's a good starting point. I find, I often end up writing light-weight wrappers on top of most libraries just to remove a lot of the boilerplate. This way, 80% of the library's usage (hopefully) ends up streamlined toward one or two specific approaches, rather than having everyone on the team trying things out and then ending up with a mess of mis-used features and squares squeezed into circular openings. I guess, this approach might apply to teams mostly consisting of Juniors who would appreciate the additional guidance, not necessarily to more experienced dev teams.
Good ideas and sounds like numbers to play around with. I will certainly incorporate that into future planning!
All in all, you are bringing up great stuff! Thanks for the quick forth-and-back.