5

Suppose, someone got a job in a software firm, and he is assigned into a 2-person team where he has to maintain source code which doesn't have any documentation and is haphazardly coded by many different staff members over the course of around 5 years. His senior team-member is also relatively new, and he is assigned in this team because some people left the company.

How should someone cope with this situation?

Improve this question
2
  • 6
    Is this someone "you"? It's kind of weird talking about someone else if we need to ask for more clarification.
    – Nelson
    Commented Jul 6, 2020 at 2:42
  • @Nelson, Yes. this is me.
    – user118911
    Commented Jul 6, 2020 at 11:33

3 Answers 3

Reset to default
9

That's a tough situation. Clearly, the company needs a developer who is better than the code :-)

Since this is workplace and not software development: What you need to do is clarify everyone's expectations. With bad quality source code that you don't know, you can either muddle through as best as you can, or you can start improving things. The latter is better in the long term.

So clarify with your manager whether the software has a "long term". If the software will be thrown out in a year's time, muddling through is not very efficient, but it's the most efficient that you can do. If the software will be used for another ten years, agree with your manager that it is currently in an unmaintainable state, and start improving it.

But the most important thing is that you talk to your manager, agree with them on the path you are going to take, and notify them that small changes and bug fixes will take disproportionately long time due to the nature of the software.

Improve this answer
3
  • inform your boss that making the code clean will take some time and money
  • if boss approves hire consultants with experience in refactoring
  • define automatically running tests
  • define a quality metrics
  • slowly refactor the mess into something readable
  • when the parts are refactored enough to have isolated modules, think about replacing single modules using appropriate patterns
Improve this answer
4
  • 2
    I told them. They replied to me that 1. They don't have any time for this 'shit', 2. If I can't continue, they will hire someone else.
    – user118911
    Commented Jul 5, 2020 at 23:40
  • 1
    I am not sure how you presented your idea, but it would be better if you give them the pros and cons for number 1. It's better to present these so that they have an idea why you need to refactor it. Seriously, for number 2, these manager should stop saying this all the time. If you are threatened like this, try finding a new job instead. If they already act like this without listening to what you are saying, only stress-filled life will be awaiting for you. Believe me.
    – ky-chan
    Commented Jul 6, 2020 at 2:39
  • 2
    @user366312, that response indicates they do not believe you or that the culture is such that “shooting the messenger” is considered acceptable (that happens a lot). The best solution is to just make a solid effort until you gain their trust and can formulate a clear path forward. Meanwhile, if it becomes unbearable, start looking for a different job.
    – teego1967
    Commented Jul 6, 2020 at 12:39
  • 1
    @user366312 reading, correcting and fixing code generally takes more skill and experience than writing it in the first place, especially so if the code is of poor quality. In that respect, "hire someone else" may actually be a correct solution - if the code is so poor that a less experienced developer can't understand it, generally the only way to fix this is to bring in more experienced senior people who can understand and handle very messy things, with the obvious drawback that it becomes much more expensive.
    – Peteris
    Commented Jul 6, 2020 at 13:47
2
  1. Accept that things will take a lot longer than you would like, and make sure that management knows that too. Understanding a big rambling software project takes time.
  2. Don't try to master the entire codebase in one go. That may take months or even years.
  3. Tackle each problem as it comes. When a problem is identified, try to work out where in the code that problem lies, and only work to understand that bit of code, and the code around it (including what it calls and what calls it).
Improve this answer
3
  • 1
    the problem is: the company sold this 'shitty' software to two manufacturing companies. these two manufacturing companies request modifications from time to time. so, I have no time to master the codebase. each problem becomes daunting at its own right.
    – user118911
    Commented Jul 6, 2020 at 11:23
  • 1
    @user366312 That's why point 3 is important. Try to fix one problem at a time. After a few years, you might actually understand the software.
    – Simon B
    Commented Jul 6, 2020 at 11:26
  • @user366312 that part is not your problem. You can't work faster than you can work; your company needs to manage the expectations of the manufacturing companies.
    – Erik
    Commented Jul 6, 2020 at 13:48

You must log in to answer this question.