2 added 325 characters in body
source | link

I am going to say no as well. Re-factoring often leads to unintended bugs if it is not managed the right way.

As a GM, periodically I would put everyone on another project and spend a week doing code reviews / re-factoring / renaming and enforcing conventions on a project. These re-factoring sprints would almost always be cosmetic in nature. Any functional re-factoring would be planned ahead of time and involve the original developer.

Functional re-factoring should always be planned and coordinated as part of the scrum process so the time can be tracked and all necessary team members are available to validate the process. One developer should not go off changing code written by another off track because most likely it is just going to mess up the current sprint for everyone. Especially when it comes to code merge time.

If it is a project which you are the sole maintainer and it is your own free time then it can be different assuming you take steps to ensure that you don't cause unnecessary delays in your current sprint.

When in doubt, ask your manager.

EDIT: I also want to mention that a given piece of code you do not like may have a certain performance target associated with it. You may not like it but it may be faster than anything you could build that suits how you want to use it. Just another reason why functional re-factoring should always be a managed process.

I am going to say no as well. Re-factoring often leads to unintended bugs if it is not managed the right way.

As a GM, periodically I would put everyone on another project and spend a week doing code reviews / re-factoring / renaming and enforcing conventions on a project. These re-factoring sprints would almost always be cosmetic in nature. Any functional re-factoring would be planned ahead of time and involve the original developer.

Functional re-factoring should always be planned and coordinated as part of the scrum process so the time can be tracked and all necessary team members are available to validate the process. One developer should not go off changing code written by another off track because most likely it is just going to mess up the current sprint for everyone. Especially when it comes to code merge time.

If it is a project which you are the sole maintainer and it is your own free time then it can be different assuming you take steps to ensure that you don't cause unnecessary delays in your current sprint.

When in doubt, ask your manager.

I am going to say no as well. Re-factoring often leads to unintended bugs if it is not managed the right way.

As a GM, periodically I would put everyone on another project and spend a week doing code reviews / re-factoring / renaming and enforcing conventions on a project. These re-factoring sprints would almost always be cosmetic in nature. Any functional re-factoring would be planned ahead of time and involve the original developer.

Functional re-factoring should always be planned and coordinated as part of the scrum process so the time can be tracked and all necessary team members are available to validate the process. One developer should not go off changing code written by another off track because most likely it is just going to mess up the current sprint for everyone. Especially when it comes to code merge time.

If it is a project which you are the sole maintainer and it is your own free time then it can be different assuming you take steps to ensure that you don't cause unnecessary delays in your current sprint.

When in doubt, ask your manager.

EDIT: I also want to mention that a given piece of code you do not like may have a certain performance target associated with it. You may not like it but it may be faster than anything you could build that suits how you want to use it. Just another reason why functional re-factoring should always be a managed process.

1
source | link

I am going to say no as well. Re-factoring often leads to unintended bugs if it is not managed the right way.

As a GM, periodically I would put everyone on another project and spend a week doing code reviews / re-factoring / renaming and enforcing conventions on a project. These re-factoring sprints would almost always be cosmetic in nature. Any functional re-factoring would be planned ahead of time and involve the original developer.

Functional re-factoring should always be planned and coordinated as part of the scrum process so the time can be tracked and all necessary team members are available to validate the process. One developer should not go off changing code written by another off track because most likely it is just going to mess up the current sprint for everyone. Especially when it comes to code merge time.

If it is a project which you are the sole maintainer and it is your own free time then it can be different assuming you take steps to ensure that you don't cause unnecessary delays in your current sprint.

When in doubt, ask your manager.