Say, I am assigned to work on a software project in a university. The software is horribly designed, and the source code doesn't even have 10% comments.

They said that they have been working on this software for 1 year. I see this software would take at most a month for me to write from scratch.

Right now, I am trying to understand the code. While I am reading the code, I have been bombarded each second by my subconscious self with the temptation to re-write the entire software from scratch.

What should I do?

  • 2
    @DarkCygnus, this is a job.
    – user118911
    Feb 9, 2021 at 0:32
  • 2
    Ask the project leader
    – Kilisi
    Feb 9, 2021 at 0:38
  • 27
    "I see this software would take at most a month for me to write from scratch." I can not count how many times I heard that, or actually said it myself. It's probably not so easy... Crappy software is usually not caused only by bad dev, but many things like unclear or changing requirements, dependancies, ... When faced with such things I would usually give the rewrite a try, maybe partly on my own time even. After 1 week you already get a better idea whether this is indeed a 1 month work or you were optimistic...
    – Laurent S.
    Feb 9, 2021 at 7:58
  • 6
    This is completely normal in software. It is as exciting as saying "I arrived at a software job and saw computers everywhere!" It is a 1000x duplicate, new programmer is shocked, shocked at low quality engineering.
    – Fattie
    Feb 9, 2021 at 14:45
  • 7
    Anytime a person says they can write something from scratch in a month, I apply the old rule of software development management - "take the time, bump up a time period and double it". So, something that the programmer says will take a month is far more likely to take 2 years to write, fully debug, and get stable with all the options needed.
    – David R
    Feb 9, 2021 at 19:54

5 Answers 5


What should I do?

You should express your concerns in a professional and polite way to the project leader.

Seems that you know who the leader is (this Ph.D. student), so you should take your concerns, to them, explain why those things are potentially wrong and if possible the general idea you have to solve those problems.

I must say again that this should be done politely and professionally. Don't go to them and say "The project sucks, it's all wrong". Just stick to the facts, say what's wrong and what could be improved, and avoid making remarks based on feelings/emotions.

In general terms there are two possible outcomes of this:

  1. The project leader takes your advice, asks you for a work plan, and you all start refactoring and reworking on the project.

  2. The project leader says "Yes, I am aware, but we must continue and complete it with what we got now".

You should be prepared for those possible outcomes (and the possibilities in between) and decide what you are willing to do on either of them (that is, decide if you are still up to the task if the second option results).

  • 1
    Spot on for the considered diplomatic approach, and for the fact it talks about refactoring and not the "complete rewrite" Feb 9, 2021 at 21:11
  • 1
    Actually, your suggestion worked. I didn't tell them that I will redesign the software from scratch. I proposed modification one after another. So, I have been able to feed them an entire elephant very slowly.
    – user118911
    Feb 15, 2021 at 4:10
  • @user366312 that's great to hear, hope that everything goes well with the project now and that you are able to bring it into shape :)
    – DarkCygnus
    Feb 15, 2021 at 4:24

You can propose the idea to your manager but, in my experience, management is generally not supportive of full rewrites.

How long would a rewrite take you? What if the ETA for a complete rewrite would be two years and you leave after one year? And what if you're being paid $100k / year. If you leave before finishing your rewrite the owner / manager just lost $100k with barely anything to show for it.

How many other developers do you work with right now? Let's say it's two others and that they're comfortable enough with it. Replacing code that two people are okay with and that you, singularly, are not, is probably not going to fly.

How old is the code base? How many other developers have come and gone that made changes to that code base? If you're using some sort of VCS you could figure this out. But if no developer over the past ten years has had issues with the code and you're the first one that is then the manager is likely going to assume that it's not the code that's the problem but you. And even if the past devs did complain about the code, if he didn't let them do a rewrite why would you assume that your request would be any different?

Also, quoting https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ,

It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don’t even have the same programming team that worked on version one, so you don’t actually have “more experience”. You’re just going to make most of the old mistakes again, and introduce some new problems that weren’t in the original version.


[When you rewrite code you] are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

If you want to maximize the likelihood that your request will get the desired response I'd prepare responses to each of the questions I've posed.

  • 3
    This is an excellent answer. And if you don't know what to do, you write unit tests if they're missing. You focus those unit tests on the parts they want you to work on, or on the parts you need to understand. In the meantime, you work on your resume and you send it out to other employers. Now at least, you know a couple more questions to ask during an interview before you accept a job offer. Feb 9, 2021 at 7:23

You have a job at this company, and I imagine very strongly your job isn't to re-write the app and waste time starting from scratch.

As someone who's been on the management side of this debate, it makes me entirely question whether I made the right hire - I tell someone what I want them to do, potentially in intricate detail, and they fail to keep their eye on the ball and do it.

If your task is to add a widget to a web page, do that. Spend time reviewing code for potential beneficial tweaks later.

100% do not waste company time on a frivolous task, even writing up why your frivolous task should be done. It will not be appreciated. That's not to say, don't spend your own time outside of company hours doing it, but you should really consider how this will be received.

Managers are likely aware of the spaghetti status of their code, and are focused on actual deliverables and features. If you can add comments and documentation as you add to the existing code, hey that's great. Proposing you ditch whatever they already have and rebuild it, however, shows an extreme mismatch on vision and experience and will likely just irritate your manager.

Not just because they'll have to say no (and really managers dislike conflict, even though they have to be able to handle it well), but also because they then need to formulate a reason. Your manager might spend a good 30 minutes trying to explain why this needs to be this way.... and at that point you haven't just wasted your own time wondering why not rebuild everything, but also that of your manager, when you could have just done what they asked you to do.

Sorry for the harsh tone in this post but i've seen it a lot and it is extremely frustrating as a manager to have employees who can't hear "Can you please build x" and then they do everything but that

^ Now, if there's a technical issue with the way the existing code is written (do NOT go looking for one just to justify your whims, if they catch you on that they'll be disgusted), it is very much appropriate to explain "I have tried building this widget this way, but the module/library we've used here doesn't support doing it that way" - this makes sense. But very definitely, don't get lost in the idea that code must be written "the right way" or not at all. In almost any company, there is an extreme demand / supply inequality as far as things development resources need to do vs how many people are available and how much time is available to do it, so proposing anything here that might waste time just so that the code will be written better... I really can't articulate how irritating that may be to others.

If you write up your own code in addition to theirs, just set an example and write it well, document it well, etc. But absolutely, do not waste time.

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Neo
    Feb 9, 2021 at 17:42
  • "Can you please build x" - a large problem of managements is they don't (want to) understand that perhaps x can't simply be built without further action. Perhaps x takes long to do without further preparation and the whole thing will crash at the latest when y should be built too? Saving time is done right when you don't count the number of things to do but sum the time these things require to be done ;-)
    – puck
    Feb 9, 2021 at 17:44
  • 1
    @puck that's what they say in the 2nd-to-last paragraph. The whole point of this answer is that mgmt may be very happy with cheap buggy software (or actually working software with simply ugly code) that kind of does what they want, and that's what the employee is paid for.
    – user
    Feb 9, 2021 at 23:37
  • @user you understood the problem ;-) Management is happy with botch because it's cheap. Not wanting to know that with some reworking future changes would be faster, that is not more expensive but more stable. Show me that one manager who, in case of problems, admits they wanted it to be that horribly bad. Then things turn quickly and nobody wants to hear that this style of work was enforced all the time.
    – puck
    Feb 10, 2021 at 18:38
  • @puck I think once you're in a situation, either owning a small business or managing a larger one, where you're controlling budgets and assigning dollar amounts to development resources... you'll very quickly understand why it is you don't want your $50/hr developer wasting an hour just compiling notes on why he thinks he should spend next year rebuilding an app he thought he could get done in a month, instead of doing what you asked him to do. Problem is exponentially worse, the smaller the user base of the app is compared to time spent / wasted
    – schizoid04
    Feb 11, 2021 at 14:20

How long have you been working there? Not very long, I'm guessing.

Please consider how you will sound when you take it to your manager. "Hey, boss, this stuff I'm working on is terrible. You should really fix it up, and I'm just the person to do it. It will only take a month!" It is very easy to sound arrogant.

Remember that you are employed to either do work and solve problems that 1) make the organization money, or 2) save the organization money or time. Everything you do must work towards that goal. If you go to your boss and say "I don't like this thing that you have here, I need to fix it", you're not going to be seen in a positive light.

If you decide to push this issue, then yes you should, as noted above "Just stick to the facts, say what's wrong and what could be improved". However, there must be a value to the work that you do, and you need to be able to quantify that value in dollars or hours. No good boss will let you change something just because it's not how you like it.

  • 2
    Plus the "Code doesn't even have 10% comments" makes OP sound like they don't know what they are talking about. A lot of comments is not the same as maintainable code. In my experience a lot of comments can be an indicator to the contrary.
    – JohnFx
    Feb 14, 2021 at 17:17

(Chuckle ...) "Welcome to the industry."

If you haven't already done so, please check-out and read: The Mythical Man-Month.

"Of course you think that you can rewrite it." "Of course you are gung-ho to try." But, what you really need to do right now is to gather up your thoughts and talk(!) to the responsible individuals – both other members of the team (if any) and the "stakeholders" by way of your manager.

"What should I do if I find that the software is horribly designed?" Well, even though this isn't how software starts, yes, it is very often what it becomes. And yet, you must find "a path forward." Welcome to the business. "Your true education" is about to begin.