The downside of writing reusable, abstracted, DRY code for multiple applications to use: you have to remember to test changes in all the contexts... my org has to hire contractors project by project as we dont have the budget to have more devs than just 1 (me) on permanently. the contractors tho often don't know about all the places our code gets used. And sometimes I even forget - last week in the rush to finish some project, we forgot to think about how a library change made for benefit of a new project a few weeks ago might effect an older (in production) project. Until shit started breaking. Annoying. very annoying. luckily i fixed it (rolled back) before the weekend, but thursday and friday were quite stressful... now tomorrow, a bunch of sleuthing time to figure out exactly what recent change caused it... argh....

  • 11

    How about that?
  • 0
    @IntrusionCM LOL. Versioning is of course part of the process but that doesn't automatically prevent someone from mistakenly upgrading an application to use a new version of a library that has a new bug in it, a bug that isn't relevant to the new project that motivated the change..
  • 1
    Sounds like you need a new major version for new projects and keep the old one for patching
Add Comment