After having worked with people in most aspects business, one of my favorite moments of enlightenment was the realization that everyone refactors.
Project management doesn’t use this term when requirements change or timelines are arbitrarily moved and they have to adjust the plan.
Product management doesn’t use this term when someone higher up wants more “cow bell”.
Management doesn’t use this term when the executive team decides to add a new project to an already unrealistic agenda.
And the list goes on… Every group is given challenges all the time. In addition, everyone is learning all the time. Some of the time this knowledge requires change. Good people will not knowingly fail.
They are all making adjustments based on new information. Refactoring.
I have never written code, walked away and never touched it again. As I gain more information about how all the pieces fit together I refactor. I refactor to simplify what typically started off as unnecessarily complicated code; to take advantage of new knowledge. Most development is done this way.
Most business is done this way.
Everyone who is honestly trying to do a good job likes simplicity as well, but you won’t hear them use that term. You’ll hear it referred to as process inefficiencies, cost overruns or other symptomatic terminology that conveys no real meaning. You don’t just fix process inefficiencies, you have to find the causes (it’s usually more than one thing).
If the company is willing to fail (I hope they are), attempts will be made to get better. Attempts that will fail, but you refactor and get better.
When change is thrust upon you remember that you aren’t perfect and this may be the result of another team trying to be better. Also, you don’t truly know what precipitated this action. If the change is potentially bad in your opinion, share your knowledge. You may see something no one else has seen, don’t assume they know.
Everyone is developing, everyone is refactoring.