As long as you are the only person usually working on the affected parts, sure. Just go ahead.
But if multiple people are working with this component or are calling it (in case you want to fix a broken interface), I think some discussion with your fellow team members would be in order as they will have to adapt to whatever you produce.
I agree on the general sentiment of not telling the boss though: It's hard to make non-programmers understand the burden that is ugly code. They think in features and whether something is "visible for the customer" (if it isn't, then it might as well not exist).
Such an attitude can lead you to having to make a decision when implementing a feature: "Oh - this code here is really shitty. I could now a) clean this up and cleanly add the feature or b) just hack the feature in somehow, maybe breaking encapsulation a bit more"
Bosses and people concerned about their free time think b), I tend to think a).
The problem with b) is that you get to your goal much more quickly (which the feature-oriented people like as it makes you seem more productive), but you are incurring dept. Now the bad code just got worse until at one point, something really breaks badly and then you WILL have to pay the price for cleaning up. This might very well be at a time where you are pressed by some deadline which means a lot of after-hours work for you.
Then again, in a team, the might or might not be you that has to clean up (you certainly hope it isn't you).
So doing it the quick route isn't just irresponsible to the project, it's also irresponsible to your team mates because they might be the unlucky ones the bad code breaks over.
So if possible, try to take those extra hours to do it the clean way. The product as a whole will get better and your team mates will not be pissed if they have to clean up your mess.
Comments
As long as you are the only person usually working on the affected parts, sure. Just go ahead.
But if multiple people are working with this component or are calling it (in case you want to fix a broken interface), I think some discussion with your fellow team members would be in order as they will have to adapt to whatever you produce.
I agree on the general sentiment of not telling the boss though: It's hard to make non-programmers understand the burden that is ugly code. They think in features and whether something is "visible for the customer" (if it isn't, then it might as well not exist).
Such an attitude can lead you to having to make a decision when implementing a feature: "Oh - this code here is really shitty. I could now a) clean this up and cleanly add the feature or b) just hack the feature in somehow, maybe breaking encapsulation a bit more"
Bosses and people concerned about their free time think b), I tend to think a).
The problem with b) is that you get to your goal much more quickly (which the feature-oriented people like as it makes you seem more productive), but you are incurring dept. Now the bad code just got worse until at one point, something really breaks badly and then you WILL have to pay the price for cleaning up. This might very well be at a time where you are pressed by some deadline which means a lot of after-hours work for you.
Then again, in a team, the might or might not be you that has to clean up (you certainly hope it isn't you).
So doing it the quick route isn't just irresponsible to the project, it's also irresponsible to your team mates because they might be the unlucky ones the bad code breaks over.
So if possible, try to take those extra hours to do it the clean way. The product as a whole will get better and your team mates will not be pissed if they have to clean up your mess.