Why the fuck do managers think beacuse a component has been build by another developer a shit ton of time ago, we can still reuse that fucking code.

For fucks sake, I had to rebuild a whole fucking map component that needed contextual filter and the fuckers just add extra functionality without consulting me. And gave me a tight schedule bc the customer, who btw disappeared for 6 months, will be mad for wasting his precious fucking time.

Fuck these clients.

Hmm, is it really that crazy to expect old code to still work later? Id argue that if shit is setup correctly, you should be able to maximize code re-use of Well tested code, no?

@Hazarth two ifs there: good setup, tests

From what OP wrote, seems that he works in a place that doesn't have any of those

Also managers have different understanding of what 'reusable code' means

@Hazarth yeah, that would be the case if the developer tested the scripts at all or made a component at least flexible enough to grab dynamic data. Not in this case.

ALL of it had to be rebuild. But the manager thinks I just twisted some thing because it looks the same.

We have usually 4 things in a project:
- code
- project management, like Jira / Tickets
- project environment, like a Team
- build and runtime chain, e.g. the build plans / infrastructure / necessary components to turn code into sth that can be deployed and then run on a server

All 4 things need maintenance - we all know the joy of not finding the right ticket because there are too many tickets ... The usual infra team warning that projects suffer from critical security bugs that must be fixed ASAP. The regular meetings to ensure team is up to date and collaborating with everyone else.

If we put aside a project for 2 years without maintenance...

We have to catch up these 2 years of missing maintenance:

Cleaning up old tickets, planning necessary updates, reacquiring knowledge... Maybe the old team doesn't exist anymore... There will be a lot of frustrating tasks till the project is back up and running.

Meaning the project will not proceed at full speed in the beginning, there will be a long time with delays till the frustration subsides and the usual pace picks up.

As a rule of thumb, we're talking about roughly 3 months - 3 months when no progress will be made, but just maintenance and getting the gears back up running.

(More or less a summary of a typical presentation on "why we cannot just restart XY).

Managers do anything but manage that’s for sure.

Depeneding on the project, just reviving it ten years later can actually work pretty well. It has to have the following attributes though:

- Very few dependencies on well-standardized and okayish maintained stuff or dependencies are non-security-critical and bundled (that is, why singleplayer games normally just work even some windows versions later).

- Requirements have not changed or the code base is available and easy to maintain.

After some years of just collecting dust, i would not prioritizing looking on old tickets or team collaboration data. You have to reevaluate the project's current state anyways. It doesn't hurt if someone likes to sift through old tickets and user stories and to clean them up. But if that is too much work or nobody wants to do it, just archiving them away and starting fresh also works. If you use it, the still valid bugs and user stories will reemerge.

@IntrusionCM @Oktokolo Both great advises. This is a small agency so timing can be very costly, fortunately the developer left some comments and used OOP to setup the component but the component was setup for dynamic content. But I guess that time got him too.

Going to prososed these next time they try to revive old code. Thanks 😃

Wait, isn't a managers job to completely misinterpret what code DOES? Mine consistently asks for features that have not been implemented yet or are wholly incompatible with existing code, making me reinvent the wheel every 3 weeks.

Isn't that their whole job description?

The amount of time I’ve wasted over the years “re-using” code from other devs is astonishing.

@Inxentas it is if they are willing to pay you for it and not bitching how the project is overbudget

...becazse thatvs how conponent should ve built if they're not shit