Htydjtk

Do not ask management for permission to refactor. It's none of their business. You might as well be asking permission to sharpen a pencil.

Management doesn't understand refactoring. It's not a business need. Management shouldn't need to understand it. It's not their job. It's yours.

Refactoring is a tool you use to satisfy managements needs. Don't ask management to think about this. I'd be very concerned if my mechanic asked me what brand of wrench to use on my car. Concerned, not about the tool, but about the mechanic.

What you need to do is to lead this team to good practices. Don't ask management to dictate that. Even if they try they'll just make a mess of it.

You need to build trust with the team, show them the benefits and the costs, and accept that change doesn't happen instantly.

Sometimes a cross cutting concern sweeps through many classes and needs refactoring. Sometimes you just can't justify doing it now because now you just need this one little thing changed.

It hurts. You have to live with working in crap code because you just don't have the time. So it keeps taking longer and longer.

Abe Lincoln is often quoted as saying, "Give me six hours to chop down a tree and I will spend the first four sharpening the ax."

When dealing with management don't argue for sharpening the ax. Argue for the six hours. Don't expect to get credit for sharpening the ax. Don't do it for management at all. Do it so you only have to spend two hours fighting the damn tree.

Understand the difference between a simple refactor and a rewrite. All too often people use the word "refactor" when the really mean a targeted rewrite. Think of the difference this way (in order of riskiness):

• 
  Refactoring is a small, easily reversed change that has no functional impact


• 
  Targeted rewrite is a focused rewrite of one aspect of an application that affects multiple parts of the code


• 
  Full scale rewrite is tossing out the old source code and starting over from scratch

The reason for the distinction here is that some code fixes have a real impact on schedule. Any time you want to do something that impacts schedule, you need buy-in. There is a way to get that buy-in, but you have to sell it as an opportunity.

Refactoring should be just something you do as good practice. Like a boy scout leaves his campsite in better condition than he found it (cleaning up other people's mess), it just happens. Many Java and C# IDEs come with refactoring tools built in, so little things like re-ordering parameter lists and renaming code is updated across the whole application. As long as what you are modifying is an internal API (not something that third parties interact with) there isn't any practical restriction.

I believe it is important to realize that a series of well targeted refactorings can add up to the same effect as a targeted rewrite, but without the same level of risk involved. I also believe that if you can't get any other work done within a sprint other than what you are calling a refactoring, what you are really talking about is a targeted rewrite. You can't commit project money (i.e. developer time doing one thing vs. something else) to something with that big of an impact without buy-in from the people who's jobs are on the line. A refactoring is the type of work that won't cause the product to slip deadlines.

Targeted rewrites need to be scoped and planned. It's like remodeling a kitchen where you have to take down a wall. There are things you need to do to support the existing infrastructure until the job is complete and new support is added. It's usually an acceptable amount of risk that brings with it some advantages you didn't have before. The code is messy during the process, but when it is complete, the application as a whole is better off.

The best way to sell the targeted rewrite is to cage it in terms of what new features the rewrite will enable your team to perform.

Whole scale rewrites should be avoided unless there really is no option. It's like demolishing a house before replacing it with something completely different. Unless you know very well how that house was used, you run the risk of the new house not meeting the client's needs.

There are times where a whole scale rewrite is indeed required, but it takes a lot of research to ensure you are addressing all the current needs of your client when you are done. There's a lot of detail that exists in the existing code that was written for some long forgotten feature that is still important. There are strategies for this type of work as well.

One concept for whole scale rewrites is to use the strangler pattern. Essentially you are building the new application alongside the old one, and using the new when you can. Less and less of the old application exists, until it is fully replaced. This allows the customer to provide feedback so that you don't miss any critical details.

Refactoring should happen as part of development. When you change behavior or add a new feature, the affected code should, if necessary, be refactored to support the change cleanly. Follow the boy-scout rule: Always leave the code in better condition than you found it.

You should not refactor code which don't need changes to behavior. You should not perform refactoring which is not related to a bugfix or new development. Don't estimate or schedule refactoring as separate from development. Like writing unit tests and performing code review, it should be an naturally integrated part of all development, not a separate negotiable option.

You encourage refactoring as part of the code review. Just ask the simple question if the code after the change is at least as clean as the code before the change was. If not, improve before the code is comitted.

Don't be a perfectionist - at least not at first. As long as every commit improves the code a little bit, things will get much better over the long haul.

It's next to impossible to convince a business to refactor, because customers won't pay for refactoring but developers still want to be paid to do it.

I would throw the question back to you. Why do you want to refactor?

• 
  

  Improve the end product

  
  
  

  Refactoring by definition means no changes to the end product. So this is a non starter

  
  


• 
  

  Speed up development

  
  
  

  A popular choice, "If we refactor this it will make it easier to change in future!". Of course, a 10% improvement of speed will take 10 times as long before you start seeing a return. It's hard to show numbers that add up to a net win.

  
  


• 
  

  Allow devs to program in the latest fashion?

  
  
  

  This of course is the fear of management, that the devs just want new toys. But you can spin it. "We are a tech company! unless we use the latest stuff and do stuff right, no one will respect our products. We have to be seen to be on the leading edge"

  
  

What Business is your company in?

• 
  

  Bespoke apps/websites to order

  
  
  

  There just no justification of refactoring, unless the customer specifically requests it, or you need to switch techs do implement their requirement

  
  


• 
  

  In house core product eg. ecommerce website

  
  
  

  Key concerns are reliability and new features. 'Refactor' to improve reliability or perhaps to add a feature "If we switch to events on MQs then we can send out product suggestions based on machine learning, as well as decoupling our microservices"

  
  


• 
  

  IT Consultancy

  
  
  

  Here refactoring to the latest ideas and techniques could be a core part of your sales pitch. "Switch to distributed-cloud-agile! (now with added truck based dev)" But you are more likely doing greenfield or POC projects where you can have everything you want.

  
  

You have to include refactoring in your designs. I understand the need to "fix" something that doesn't seem appropriate, but you need to be honest in terms of what the refactoring of finished, tested, certified and working (in prod) code will provide to you and your company. You shouldn't change something that has been working, doesn't have major bugs or performance issues, and is providing value to your stakeholders. This is very visible to them, and it is why they'll (most likely) never allow time for unnecessary changes.

You have to be smart about it. You are (i think) providing maintenance to this software. New functionality will require some design so whenever you need to change the code, don't do a surgical, pragmatic change and commit to building the correct solution for the problem. This will likely involve refactoring of the existing classes.

Something your question lacks, which is also likely the reason that you couldn't pass it by Management, is demonstration for the need for refactoring.

Refactoring is a risk, so you need to show that the "expected return" is a net positive and that the damage can be mitigated if things go south.

However, if you CAN demonstrate that the expected return is higher than the cost, then surely no one will disagree with you.

It's possible that refactoring is outside of management's power too--depending on your company/projects, your company may not actually own the codebase you are working on. Working on changes not requested by the client may be a breach of contract.

I'm asking what are some ways I can help create a culture of writing
for maintainability rather than pure functionality

With a team of 20, I'm assuming you have meetings and (hopefully) code-reviews. These would be a good time to share your concerns about coding styles (ideally a coding-guideline would exist) and design patterns. Again, you will need to demonstrate an advantage to this! Changing coding styles requires effort by all members to change, maintain and enforce, but if people generally agree that you made a valid argument, it shouldn't be hard to continue.

If you need to convince your lead, somethings they may be considering (that you need to convince them will not be an issue):

・Depending on the complexity of your code, free reign for refactors will likely lead to a lot of "Why did this break??" "Oooh! I didn't know that was weird like that for a reason!" (In other words, it's not ideal, but sometimes things are how they are for a reason, a reason which the lead will likely know and have under control and not want people poking at)

・Things may start taking longer than the lead expected, so the lead needs to be prepared for that (ie budget more time)

PS, this sounds like it should be in stackexchange WorkPlace rather than software engineering

Mind the Economics of Refactoring

Refactoring

• does not affect functional aspects (otherwise it's more than refactoring)


• therefore affects non-function aspects only (also known as quality attributes).

There is an inherent cost associated with refactoring, and the benefits of refactoring must surpass that cost:

• 
  refactoring costs time, and therefore money (in commercial environments)


• 
  opportunity cost: this time could be spent for something better (adding functional value or delivering earlier, or improving quality aspects in another way)


• 
  risk: the outcome could be worse than what you had before, or it could take longer time than planned. Therefore a save margin has to be added to the refactoring costs.

The benefits have to be quanitified as well, in terms of expected improved quality aspects (https://en.wikipedia.org/wiki/Non-functional_requirement): the refactoring can

• 
  save you time (and thus: money) in the future (for maintenance and faster addition of new features)


• have significant quality improvements that can be monetarized (payed by current or future clients)

So, for every refactoring, consider:

• What are the expected benefits, and how and when will they will pay off


• How much time/money you have to invest, plus risk uplift

Bad situation: The code could need a refactoring, but the benefits of doing so are marginal, and it is late in the project, and you're in a fix-priced, one-shot project that won't be continuted save for serious bug fixes.

For small refactorings: those decisions can be made by the developers themselves as by the boyscouts rule: leave the code/campground in a better condition than you found it.

For larger refactorings: management attention (project lead) and feedback (peer developers) are strongly adviced before wasting potentially precious time on a refactoring. Peer developers may get relevant input or advice for the refactoring (which usually can be done in more than one way), and lessons can be learned (both by you and others).

This is not a team problem, because it is never a team problem. This is a management problem, and the question you need to answer is this: Does management understand what technical debt is, and why it's important to service it - and more importantly, do they care?

In the majority of businesses where software is not the core focus, management doesn't understand or want to understand software, because they don't see it as important. If this is your scenario, then you need to put a presentation together explaining why you need to refactor software (i.e. risks of not refactoring) and pitch it to the relevant managers. Either they will get on board with you, in which case you can start introducing it gradually, or they won't - in which case you either have to continue dealing with a rotting codebase forever, or find employment elsewhere.

If, however, you're working at a software-focused business where refactoring isn't a core focus, you need to get the hell out, pronto. There is no other option, because such businesses (and yes, I have worked at one) will never change their practices, regardless of what they may claim, because they literally cannot afford to spend their time in any other way than pitching the lowest bid to the next client, and lowest bids don't include refactoring time.

You need to make it a fun and exciting thing to do. We call it "The Quality Offensive". A code analyser runs overnight and generates lists of things which could be done better. These tasks hang around in Jira, it's a good Friday afternoon job to pick one up and do your stuff. Newbies do this full time for a week, till they get the feel of stuff. There is actually a table in Jira for how many buglets someone vaporised in a task before checking back in. And if you get that little blob to turn from red to yellow to green you are a hero, deep inside.

After you've done this a while - combine these if statements, comment this function, remove this unused code - you find you do it anyway while coding, just to save someone else the trouble later. And there's always the little nagging thought "I don't want Lint to find things to complain about in my code".

It is very important that no-one gets blamed for the not-quite-bugs. They are just there, like rats in sewers, you are trying to reduce their number for the common good.

It doesn't matter which of the many excellent tools you use, just get one - maybe a 30-day trial installation - and let it rip. You have to adjust its parameters till it gives you useful output. Try different ones. We actually have two different ones running.

I see more problems than just a refactoring here.

I've also asked management if we could have some more deliberate planning or cleanup for the codebase but I was basically told no.

Did you talk to your direct team lead? Management is a very broad term, and can include anything from team lead of your 20+ people up to a a CEO of the entire company as well as other company pillars' management (aka Operations or Business management; note that any level CEO is usually more of Ops/Bus as well).

Essentially the person you have to persuade is your direct (line) manager. The one responsible for the team. If you manage to convince them, you're on the right way. It'll be then their decision if they want to apply changes without notifying anyone or seek further approvals. They are also responsible for building the culture of coding.

I've had some 1:1 conversations with team members and most of them are also aware of the various code smells and don't like them

This means you actually have a very strong basis. In most companies there are team meetings and there you can bring up the point of improving your coding practices in general. Talk upfront to 2-3 colleagues that you think might be most interested in it as well so that they can back you up at the meeting. That will strengthen your discussion position.

Prepare your arguments. Look for the analysis of impact to the code, programming efficiency etc when it is not written properly. The term "technical debt" has been already mentioned in other answers. This is what you need to look for in general.

Think also about actual problems that you or your colleagues/a whole team experienced due to those problems. Will you be able to spend less time if the code was uniform? Will there be less errors during code integrations?

Everyone on the team programs in their own way and there isn't any coordination.

This, rather than the refactoring itself is the main and first thing to address. What's the point of refactoring if you will be back to the same (lack of) code quality in another 2-3 years (at best). In reality your refactoring will be slower than introducing the new code, so it will be simply a waste of efforts. Focus on discussing how to improve new code quality in the first row, agree on the practices to follow, add code reviews as a mandatory part of your coding to ensure the practices are followed.

In other words - stop doing more mess (aka acquiring more technical debt). Of course, you'll always have challenges with that and sometimes you might end up with some deviations from the standard but each deviation should be immediately fixed before moving on to the next project.

but refactoring rarely happens because there is always something more important to do.

Once the previous point is achieved you can move on to the refactoring, In reality make it a part of your coding practices immediately but only once the standards are settled.

Refactoring is not about making a huge single change (again - as already pointed out in other answers). It's about continuous improvement of parts of the code neighbouring what you currently write. Make it a custom that you're fixing a line of code or function that you're about to use. Just one at a time. Make sure to have unit test (if you don't writing them one is also a part of your refactoring).

With this approach it'll be easier to blend the refactoring into everyday work. You need to account that when assessing the workload for the actual coding. Only if you give yourself the required time, you'll be able to do that. And no-one will most probably object, since they have no idea what you are really doing. Of course as long as you have your managers consent.