1

I work in finance and we have some calculators that I support. I can come up with programming solutions, but I don't have a lot of software design or release management experience.

I was recently asked to approve coworker's code. The enhancement was fairly simple, but during my review I realized they came up with their own method to process input files. We have generic methods that could already be confusing for newhires with only classroom programming experience, and I don't want to make onboarding any more difficult by propagating poor design in our code base.

I'm concerned that since we're not a software shop, my managers won't prioritize refactoring once the problem has a working solution. How hard should I push to keep our code clean for the release?

Alex F
  • 121
  • 5
  • This question must be improved in several ways. It's currently a "wall of text". Please do some formatting, what's not essencial and be more direct in what you expect, otherwise you will not get helpful answers. – Tulains Córdova Jan 27 '15 at 17:36
  • @user61852 - I am not sure I agree. It provides the background of the situation and is broken out into coherent paragraphs. – Telastyn Jan 27 '15 at 17:58
  • 1
    @Telastyn It was bastly improved after my comment. See the edit here: http://programmers.stackexchange.com/posts/271305/revisions – Tulains Córdova Jan 27 '15 at 18:04
  • possible duplicate of [How can I convince management to deal with technical debt?](http://programmers.stackexchange.com/questions/43948/how-can-i-convince-management-to-deal-with-technical-debt) – gnat Jan 27 '15 at 18:17
  • instead. this is also an option. – shabunc Jan 27 '15 at 18:58

2 Answers2

9

You'll want to read up on the term "technical debt".

If time & resources permit, it is much better to do any code clean up immediately while the problem is fresh in your mind.

Leaving clean up as a to-do item for others can turn into a very bad habit. These to-do items are rarely addressed, and after many years can lead to such a horrific mess that management dumps the entire system and fires people (I've seen it happen).

Dan Pichelman
  • 13,773
  • 8
  • 42
  • 73
  • 1
    I've seen it happen too. Often the people who get fired had nothing to do with the original mess. The reality is that technical debt can lead innocent people to financial bankruptcy. – RibaldEddie Jan 27 '15 at 18:55
1

If any of this is applicable to your situation, you'll know what to do:

  1. A correction is made to your generic methods, but the code that created their own is still broke.
  2. You spend time teaching another new candidate that "all the code uses the generic method" but they have to fix the one that doesn't. Now you get to take more time to explain how to fix this. You were expected to be able to fix these types of problems sooner, but now there is a delay.
  3. Because you don't enforce the rules, your team turns into a bunch of Cowboy Coders. The performance of the team drops.

Don't ask permission to take the time to do things right. Everyone assumes you already are and that's why everything in their mind seems to take longer then they think it should. If your boss has to clean up this mess, he's going to do it by replacing you.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • Thanks for the advice, I plan to push back on the release. "Don't ask permission to take the time to do things right." is not a fair assessment though since it's not about asking permission, it's about delaying the project. – Alex F Jan 27 '15 at 18:06
  • You should delay the project to do things right. The easy route is to let someone else be forced to deal with it in the future. That very likely will cost the company more money than fixing it now. Despite all the good intentions, technical debt (as pointed out above) is rarely returned to. Whatever path is taken, know that it sets an example for all your programmers. – JerryOL Jan 27 '15 at 22:28