4 ms·

And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do

And some people are sick to their back teeth of listening to new devs come in and whine about poor code without understanding any of the context. Perhaps you do know better than everyone else, but you ought to make damn sure of it before you open your mouth

Aaargh20318 8y ago
The first course of action if you find some ugly/bad code is to ask a dev with more history with the codebase why it's like that. In my experience 9 times out of 10 the answer is "we know, it's like that because of reason but we haven't had the time to fix it yet".
- pbhjpbhj 8y ago
  Surely in a commercial setting the primary factor is RoI rather than time? Will rewriting this old, stable, code increase profits or substantial reduce revenue impacting risks? #notacoder
  - TheGrumpyBrit 8y ago
    Often, it's a simple case of business need. As long as the offices are clean, the business doesn't really care if the cleaning cupboard is tidy. It applies to a lot of business areas. If you want to introduce new processes or fix any problems, you need to justify why you want to do that, and "This isn't very pretty" isn't generally considered a good enough reason. If something works, nobody ever got into trouble for leaving it alone.
  - maxsilver 8y ago
    > Surely in a commercial setting the primary factor is RoI rather than time If it's a smaller company (op mentioned 50-100 people) they might not even know what RoI is, and/or might not care about it.
    - pbhjpbhj 8y ago
      That's a strange comment, surely it's impossible to stay in business and not understand RoI to some degree.
  - anewone 8y ago
    Same thing. The time is the investment. There are always projects with better RoI so a rewrite is constantly at the bottom of the pile. "We'll get to it someday."
  - imdark 8y ago
    It really does depend, any code, especially bad code, is very rarely bug free. So if you ever need to fix a bug the amount of time you will need to spend and revenue you might lose during the time might be worth the refactor beforehand In my experience, software or product development is never really "done" Customers, users and business will ask for new features and change of old features, external dependencies and used services will change, hardware will change Not being able to move fast enough, train new engineers and adjust to changing requirements will have a cost If I can't trust my codebase not to break on any new change it will be much much harder and more time consuming ie expensive to maintain it This is not applicable to every piece of code and roi should always be kept in mind but I'm my experience it is almost always the case
- jaclaz 8y ago
  Not necessarily related to code, more or less you just re-wrote a sort of Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
mattmanser 8y ago
I think if it's so frequent that you're sick to your back teeth of listening to people complain about your code, it's probably a really sure sign that something is very wrong with the code.
- circlefavshape 8y ago
  Haha, good answer :) It's rarely my code they're whining about though

Aaargh20318 8y ago

The first course of action if you find some ugly/bad code is to ask a dev with more history with the codebase why it's like that. In my experience 9 times out of 10 the answer is "we know, it's like that because of reason but we haven't had the time to fix it yet".

pbhjpbhj 8y ago
Surely in a commercial setting the primary factor is RoI rather than time? Will rewriting this old, stable, code increase profits or substantial reduce revenue impacting risks? #notacoder
- TheGrumpyBrit 8y ago
  Often, it's a simple case of business need. As long as the offices are clean, the business doesn't really care if the cleaning cupboard is tidy. It applies to a lot of business areas. If you want to introduce new processes or fix any problems, you need to justify why you want to do that, and "This isn't very pretty" isn't generally considered a good enough reason. If something works, nobody ever got into trouble for leaving it alone.
- maxsilver 8y ago
  > Surely in a commercial setting the primary factor is RoI rather than time If it's a smaller company (op mentioned 50-100 people) they might not even know what RoI is, and/or might not care about it.
  - pbhjpbhj 8y ago
    That's a strange comment, surely it's impossible to stay in business and not understand RoI to some degree.
- anewone 8y ago
  Same thing. The time is the investment. There are always projects with better RoI so a rewrite is constantly at the bottom of the pile. "We'll get to it someday."
- imdark 8y ago
  It really does depend, any code, especially bad code, is very rarely bug free. So if you ever need to fix a bug the amount of time you will need to spend and revenue you might lose during the time might be worth the refactor beforehand In my experience, software or product development is never really "done" Customers, users and business will ask for new features and change of old features, external dependencies and used services will change, hardware will change Not being able to move fast enough, train new engineers and adjust to changing requirements will have a cost If I can't trust my codebase not to break on any new change it will be much much harder and more time consuming ie expensive to maintain it This is not applicable to every piece of code and roi should always be kept in mind but I'm my experience it is almost always the case
jaclaz 8y ago
Not necessarily related to code, more or less you just re-wrote a sort of Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

mattmanser 8y ago

I think if it's so frequent that you're sick to your back teeth of listening to people complain about your code, it's probably a really sure sign that something is very wrong with the code.

circlefavshape 8y ago
Haha, good answer :) It's rarely my code they're whining about though