3 ms·

Don't fix things just for the sake of fixing them. Let new features, bugs, or necessary performance improvements drive your changes. Keep your changes small and

Don't fix things just for the sake of fixing them. Let new features, bugs, or necessary performance improvements drive your changes. Keep your changes small and focused. You need to ensure that you're delivering business value with each change, rather than embarking on an overwhelming, open-ended task. This is critical if you want the business to support your effort. It demonstrates pragmatism. It will shrink the scope of your changes and make the problem less daunting. You can prove to your boss and your coworkers that it's possible to fix the problem without slowing down new development efforts. Be careful how you express your dissatisfaction with the code. Many of the people who wrote it are likely still there. Approach every change from a positive angle, so you don't alienate your peers. Get them to help you make the changes, and help them to learn how to become better developers. Don't assume they don't know better; they may have inherited a mess too, and they may have been under pressure to deliver quickly at any cost--or maybe they just don't know any better, but want to improve. Read these books: _Working Effectively with Legacy Code_ by Michael Feathers _Refactoring: Improving the Design of Existing Code_ by Martin Fowler _Clean Code_ by Uncle Bob These are invaluable resources. There are many others, but these three are particularly germane to your situation.

marcus_holmes 8y ago
I would agree. Your job is to implement the new features and leave the code in a better state than when you found it. As a professional programmer, your job is not to produce beautiful code. Your job is to make money. There is a commercial decision for the organisation to make about paying back the tech debt in this code base. That's not your decision to make. Likewise, it's not your decision to create more tech debt if you can avoid it (sometimes you can't because deadlines are more important than tech debt). As the parent said, your best course is to implement the new features, and refactor where it makes sense to do that to support the new features. But without any test suite, you risk breaking the existing features by doing anything more than the absolute minimum of refactoring. That's bad. Good luck. And welcome to the profession hehe
arendtio 8y ago
I don't agree with the first part. I have worked enough time on the management side to understand that management is always driven by business value (it's their job). So your point 'Let new [...] drive your changes' is valid to some extent. But business value doesn't always mean that you need new features to justify working on a project. Sometimes it is possible to justify working on something just by explaining technical debt and how much time it will cost in the future (e.g. slow you down). Working in an unstable environment can drive you crazy as a developer and lower your productivity enormously. So if you don't talk about the issues in the code base with the management, they might wonder why you have lower output then others and classify you as a slow programmer. Instead, I think you should bring the facts to the table (slow down factor (number of bugs, time to trace them down), risks (likelihood of production issues)), in terms of how much time it costs to work within the current code base and let the management decide on how to proceed (make sure to bring a recommendation). If they are willing to let you spend time on improving the quality, try to modularize it so that if the rewrite will be stopped at any time, the time you spend refactoring it helps you in the future. While doing so, show respect to the programmer that worked with that code base in the past (even if she/he create that mess). You don't know under which conditions she/he had to work, how she/he learned to programme or what her/his life looks like outside the job. The management basically has these options: 1. just minor changes to the code base: no rewrite, no hidden quality enhancements (might be a valid option if an alternative software is being developed already). 2. hidden improvement: no rewrite, but you are allowed to spend some extra time to improve the parts you are working on. 3. restructuring of the code base and systematically writing tests for different modules (recommendation). 4. complete rewrite: unlikely to happen unless it is cheaper than 2 and 3. If the management decides to continue with option one or two, do the best you can under the circumstances be pragmatic as caymanjim wrote. Make sure to include option four so that the management sees the full spectrum of options at hand.
jschulenklopper 8y ago
Just a quick note: Martin Fowler has been working on a second edition of _Refactoring_, and IIRC it is expected to come out this Fall. See https://martinfowler.com/articles/201803-refactoring-2nd-ed.html https://martinfowler.com/articles/201803-refactoring-2nd-ed....
ebiester 8y ago
I came to recommend Feathers' book. Those strategies will save your bacon when you go to solve these problems. I put it in the "must read" list for all mid-level engineers. To be fair, I put all three of those in my must read category.

marcus_holmes 8y ago

I would agree. Your job is to implement the new features and leave the code in a better state than when you found it. As a professional programmer, your job is not to produce beautiful code. Your job is to make money. There is a commercial decision for the organisation to make about paying back the tech debt in this code base. That's not your decision to make. Likewise, it's not your decision to create more tech debt if you can avoid it (sometimes you can't because deadlines are more important than tech debt). As the parent said, your best course is to implement the new features, and refactor where it makes sense to do that to support the new features. But without any test suite, you risk breaking the existing features by doing anything more than the absolute minimum of refactoring. That's bad. Good luck. And welcome to the profession hehe

arendtio 8y ago

I don't agree with the first part. I have worked enough time on the management side to understand that management is always driven by business value (it's their job). So your point 'Let new [...] drive your changes' is valid to some extent. But business value doesn't always mean that you need new features to justify working on a project. Sometimes it is possible to justify working on something just by explaining technical debt and how much time it will cost in the future (e.g. slow you down). Working in an unstable environment can drive you crazy as a developer and lower your productivity enormously. So if you don't talk about the issues in the code base with the management, they might wonder why you have lower output then others and classify you as a slow programmer. Instead, I think you should bring the facts to the table (slow down factor (number of bugs, time to trace them down), risks (likelihood of production issues)), in terms of how much time it costs to work within the current code base and let the management decide on how to proceed (make sure to bring a recommendation). If they are willing to let you spend time on improving the quality, try to modularize it so that if the rewrite will be stopped at any time, the time you spend refactoring it helps you in the future. While doing so, show respect to the programmer that worked with that code base in the past (even if she/he create that mess). You don't know under which conditions she/he had to work, how she/he learned to programme or what her/his life looks like outside the job. The management basically has these options: 1. just minor changes to the code base: no rewrite, no hidden quality enhancements (might be a valid option if an alternative software is being developed already). 2. hidden improvement: no rewrite, but you are allowed to spend some extra time to improve the parts you are working on. 3. restructuring of the code base and systematically writing tests for different modules (recommendation). 4. complete rewrite: unlikely to happen unless it is cheaper than 2 and 3. If the management decides to continue with option one or two, do the best you can under the circumstances be pragmatic as caymanjim wrote. Make sure to include option four so that the management sees the full spectrum of options at hand.

jschulenklopper 8y ago

Just a quick note: Martin Fowler has been working on a second edition of _Refactoring_, and IIRC it is expected to come out this Fall. See https://martinfowler.com/articles/201803-refactoring-2nd-ed.html https://martinfowler.com/articles/201803-refactoring-2nd-ed....

ebiester 8y ago

I came to recommend Feathers' book. Those strategies will save your bacon when you go to solve these problems. I put it in the "must read" list for all mid-level engineers. To be fair, I put all three of those in my must read category.