4

At my new organization , they love spaghetti code, they neither want me to refactor it, because it works. Special thanks to php.

Comments
  • 4
    If it works and does not block ypu from baking in new features -- noone's gonna pay for your desire to have a cleaner and better organized workspace. They've already paid once for that code. Why should they pay again....? It works, ffs. They aren't gonna generate more $ if you refactor it.

    Yes, everyone would absolutely benefit from it in the long run. But it's your, the engineer's job to make it well and right at the first try. W/o the need for refactoring efforts 2 months later.

    That's why we have clean code. That's why we have design patterns. That's why we have verbose identifiers and zero comments.
  • 3
    What @netikras said. +1 . But ethically you _should_ employ some sort of best practices to coding to reduce the #spaghetti nature of it
  • 2
    @netikras they are a bug factory , developers who work on those years old code will take more time to understand whats happening inside while adding a new feature or solving a bug. It simply sucks developers time which they are paying for. It took me more than 2days just to add validation to 5 forms, validation was only on javascript and one function has more than 400 lines of code without any modularity.
  • 0
    @vvinu9876 yes, it's a bug factory. Yes, it's tedious and hard to work with. As I've said, everyone would benefit in a long run, yes. But unless your company advertises itself as a bunch of dum-dums, clients expect to pay only once for a feature they request.

    Look at it this way. You hire a guy to build you a house. You pay him for the land and materials in advance. He builds the walls, windows, roof. When it comes to painting, he comes back to you "the walls are poorly made, I can't paint them. I'll need €17k more to tear down and redo the walls, otherwise they'll rot within a year. And after walls are refactored, there might be some new faults I cannot account for in advance"

    would you pay him gladly to remediate his own failures?
  • 0
    I know you disagree and I know that's why you just skim through my messages thinking I don't know how bad your case is and I can't possibly know how bad you need it.

    Believe me, we've all been there.

    If you want to refactor it, there are only 3 ways:

    1. You do it yourself, on your own time [or cover that time by overinflating other tasks' estimates]. Bottom line - client does not know that you're refactoring anything

    2. You agree with the client in advance that there will be additional maintenance expenses throughout the project, and also agree on the amounts/numbers on advance.

    3. An emergency need for refactoring: some feature cannot be added bcz code design does not allow for it; a mysterious bug can only be fixed by refactoring, etc. The client is cornered. NOT A GOOD PLACE TO BE IN for either of you.

    If you choose either of above, make sure you redesign the code properly, so that 7 features later there isn't a need for another refactoring. The code WILL mutate. Always.
  • 0
    @netikras we are a product company
Add Comment