Conversation

Notices

1. Embed this notice
   bert hubert 🇺🇦🇪🇺🇺🇦 (bert_hubert@fosstodon.org)'s status on Saturday, 14-Dec-2024 23:44:12 JST bert hubert 🇺🇦🇪🇺🇺🇦

   Doing a (brief) presentation Monday on long term software development (>10 years). Things you regret in year 8. I'd love to hear things you found out and wished you'd done differently. Or conversely, what worked out really well. Will turn this into a public presentation & blog post. To kick it off: PLEASE KEEP YOUR CODE AS SIMPLE AS POSSIBLE.

   • Embed this notice
     Ayo (ayo@lonely.town)'s status on Saturday, 14-Dec-2024 23:44:12 JST Ayo

     in reply to

     @bert_hubert Having worked on one project for 17 years, the best decision I've made was to minimize dependencies and choosing tech that seemed like it'd stick around for a while.

     I've had much more recent projects where I already regretted using a library that broke within a year or two and isn't being maintained anymore.

     Haelwenn /элвэн/ :triskell: likes this.
     alcinnz repeated this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Sunday, 15-Dec-2024 00:01:09 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ayo
     @ayo @bert_hubert Reminds me of the questions I have when I choose dependencies:
     ① Are other people using it? (easy to check via distros like Alpine or Gentoo)
     ② Could I end up maintaining it? (either due to upstream passing me maintenance, or needing to fork/patch it)
     
     Question ① isn't very important but makes sense to check, could otherwise end up missing a better dependency without doing so, and sometimes turns out the dependency is used by no one because it's unusable.
     Question ② is probably the most important, could skip it for throwaway scripts but well… temporary sometimes spans for a very long time.
     
     Note: I tend to consider not just libraries but also utilities, buildsystems, language implementations as part of the dependencies. Could even consider deployment like packaging into distros in there as well but can't really call that a dependency of the software.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 18-Dec-2024 20:05:59 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ayo
     • Frank Heijkamp
     @alterelefant @bert_hubert @ayo Yeah and no.
     Operating systems, file formats, protocols, … do change, and dependencies can help on this part, so you'd have to be careful to not minimise too much.
     And picking a dependency should mean keeping an eye on it, hence the question of possibly ending up maintaining said dependency.
     
     And future proof… I think the best way to approach the future proof ideal is to allow independent implementations to be made.
     You can have code which should work well in the future but realistically there's no telling what will happen in roughly 10 years. Which to me is a rather short timespan for software, but enough for big changes to happen.
   • Embed this notice
     Frank Heijkamp (alterelefant@mastodontech.de)'s status on Wednesday, 18-Dec-2024 20:06:00 JST Frank Heijkamp

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ayo

     @lanodan @bert_hubert @ayo In some cases it makes sense to code your own packages instead of relying on external parties. Minimising the number of dependencies stands out to be the most effective way to make your system future proof and easy to maintain.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Wednesday, 18-Dec-2024 21:03:50 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Ayo
     • Frank Heijkamp
     @alterelefant @bert_hubert @ayo npm-dependent web development always seems quite ass-backwards to me.
     
     Like web browsers have pretty good API compatibility between each others and APIs very rarely break, same thing for NodeJS itself.
     
     One thing that's lacking is the JS standard library, so if you want to target both browsers, NodeJS, … you're definitely going to need wrappers and maybe few libraries. Which okay makes sense, you're targetting different platforms.
     
     But then you have build tools and frameworks that are so API-unstable that keeping up is a challenge.
     Which makes no sense and just means that using them undermines what otherwise would be very stable platforms.
   • Embed this notice
     Frank Heijkamp (alterelefant@mastodontech.de)'s status on Wednesday, 18-Dec-2024 21:03:51 JST Frank Heijkamp

     in reply to

     • Haelwenn /элвэн/ :triskell:
     • Ayo

     @lanodan @bert_hubert @ayo It is always a fine balance between what is good for the short term and what is wise for the long term. Especially in web development there are new frameworks and related components popping up left, right and center. One should always think twice before jumping on the next hot thing that comes along. Keep it simple and have future maintenance in mind. That might mean that you have to do a little bit more work now in order to save time and money in the long run.