Working with very bad code but on a deadline

Question

I am currently working as a newly assigned lead developer (just in name, not really leading anything) on the frontend code for a project which my employer wants to deliver to various clients.

Unfortunately, the code has been written by a backend developer (inexperienced frontend developer). It combines some of the worst practices and the coupling is horrible. Working with the code and architecture is a pure horror but they have a deadline. I literally told them it's not possible to deliver with this horrible code base. It also somewhat mixes business data with styling. Not to mention the product looks really bad.

Well, they weren't happy and think the code is just fine. As a countermeasure I made a proof of concept in my free time and showed them how clean and modular code can be, especially with data binding (React), state management, etc. with a fast and nice looking UI. I literally recreated it with 80% of all the required functionality in only 2 days, including unit tests but totally maintainable. There was no positive reaction because they thought it was rude. In fact, they told me I need to adjust to the team. Focus on the deadline. I told them it can't be reached. I told them the code base has been written by this one person and since they have given me the lead, I'm giving my opinion, which I strongly believe is true. However, the guy who programmed this code is busy in a different project.

In the end, I need to work with this code and well, there is a saying: garbage in, garbage out. I'm still not done for things that should have been easy to do. Deadline could not be met. Now we have a new deadline.

What exactly should I do? I could easily solve the problem rewriting all this garbage in 5 days, which would even include unit tests but I'm not allowed to, due to the upcoming deadline and the belief that the code is "working" and that it would be a waste of time and money to write professional code.

The problem? Most colleagues say it's fine because apparently they respect the guy who wrote the code who is a senior Backend Dev. How can hundreds of "if" statements and nested "if" statements be good? Crazy handling of props. No state management. Custom event bus in a Vue app instead of reactivity? Hard coupling? Side effects? What about DRY principles? I'm seriously losing my mind.

What exactly am I going to do if I can't meet the deadline? They expect me to be able to work with other people's code BUT this code is truly apocalyptic and the more we build on it, the more it will establish as a product.

Answer 1

You swallow your pride and you deal with the crap architecture and try to make the deadline.

Your boss hasn't got a problem with the architecture. You can try to convince him when there is less time pressure. But for now, you need to deliver what is considered the MVP to meet the deadline.

Businesses exist to make money. They don't exist to write good software.

Ultimately poor architecture will come back to bite. You need to figure out if you want to be around when that happens, if you can't convince your boss that things need to change.

Answer 2

The key here is to do what you can. This kind of situation is normal and will probably occur throughout your career. It is the kind of thing that the agile process was meant to address.

What are the requirements for the deadline? Focus on those. Get as many of those completed as you can. Try to identify the ones are the most important and do those first.

There may come a time when you can refactor and improve this design. That is when you can implement best practices. Until then do the job that your bosses want done, that is complete this less than optimal design.

Many big companies, with big development budgets have poor websites. This despite their desire to push customers to use their online accounts rather than calling/emailing/going into a store front.

So this project will not be the first sub optimal design, and it is probably a lot better than most.

Additionally, while your complaints may be warranted, management does not want to hear them. They pay you the big bucks for a reason: Solve the technical problems to deliver a solution by the deadline. Continuing to complain will give you a bad label.

One of the best pieces of advice I put into practice fairly recently was: If people are not listening, stop talking. My nature, is to be more adamant but that just backfires.

Answer 3

I have been in your position before. I was told to work on a website with an terrible code base and deliver it before deadline. Here is what our team did,

1. We completed the initial delivery with the bad code.
2. Whenever there is a new feature, we would say "This feature won't work good with current architecture" or "With the current architecture it would take atleast x more days" and buy some extra time. We then used this extra time to refactor the code related to the current sprint.
3. A couple of sprints later, we had completed all major tasks and improved the code a little bit. I then convinced the management & clients to allocate 2 months to fully refactor the code to modern standards. I told them, it would help us to make changes more easily and deploy updates faster (which was true).

Now we have a code that is up to modern standards we want.

Answer 4

NOTE: OP is the lead front-end dev per comments

What decisions are you empowered to make? Clarify this with your manager in an email. Can you piece-wise replace it? Don't bad-mouth other developers!

Your boss may have heard "rewrite" a few too many times and seen it fail. Try another approach - set a code standard your boss can review. The code standard will specify patterns for view, models, etc. MVVM for example.

All new work will use this standard. If existing code is touched, it is rewritten to this standard. Bring your boss in on making the standard, and get buy in from all the other front-end developers on the team.

Part of leading is getting consensus from direct reports and managers. Make sure to focus on business outcomes, not technical details. Dealing with a bad code-base should be part of your job as a lead developer.

Don't bad-mouth the backend developer. He's probably "got it done" and saved your boss several times. Talk about freeing him up to focus on the backend.

Part of being an employee is doing what management says even if you think it's a bad idea.

You likely inherited some deadlines. In the short term your job is to meet them, even if the code isn't ideal.

You won't be able to do everything you want. That's part of working as a team of employees. Work with management to move the codebase forward. You will have to compromise.

Finally, if you don't feel you can do your job effectively, it's time to look for another job.

EDIT

Part of your job is setting and enforcing coding standards and communicating realistic expectations with management. Even with non-technical management you can explain coding standards.

We're switching to industry best practices that are outlined in the official documentation here. This way when we hire new people they'll be familiar with code layout and get up-to-speed faster. For the current team I'll be easier and faster to write code an unit tests.

You can get the team onboard by letting them help craft the new process. Part of leading is getting everyone on-board. Use your CI/CD pipeline to enforce code review and probably do the first few as a group so everyone sees the standard.

Answer 5

As a manager, I frequently encountered the 'not invented here' syndrome; software developers would insist that some code written by a co-worker was sub-standard, and needed a re-write - and then they'd use up several weeks of a tight-timescale project to do exactly that.

We're not in a position to judge whether your criticisms are justified, or whether this is a case of 'the best is the enemy of the good', but beware going out on a limb with some new development method; you could find yourself in conflict with co-workers who are really comfortable with 'the old ways', so would like to see your project fail - and that is a very uncomfortable position to be in.

Answer 6

For me you are just discovering what it is like to work in a company.

There are requirements, deadlines, ... And you can not always do what you want.

You did not say if you are new to that company (and therefore did not had time to prove what you are capable of). Maybe the back-end guy is someone who has been in the company for a long time and have save them from previous troubles.

Also what you did not take into account is the rest of the team. They are used to the code as it is and if you rewrite everything from scratch they will lost the knowledge they have on their product.

A lot of companies have bad codes with big technical debts and you have to deal with it. Try to show you knowledge and improve the quality of the future projects but for this one, I think, you should better leave it as it is and do what you can without losing time by trying to prove you can do it better.

Answer 7

If you were a regular dev, I would tell you to find better ways to push, but ultimately do what you're told (and see if that's the way you want to work).

Since you're the technical leader, my advice is: Run Like Hell. They don't trust you, at all. You are the expert, yet from your question your manager disregards your opinion on everything. I've seen managers trust junior developers more than what you say they trust you. Go somewhere where they treat you like the expert you are (even if you don't end up with the technical leader title).

If you're intent on staying there, one way you could push for a rewrite is through small refactors. "Small" is a relative term, but I would try to keep them as small as you can (not easy if the bad code is tightly-coupled). For every functionality that you need to do, refactor everything you touch while you're at it. It's going to be harder than building the thing from scratch, but you will be delivering functionality incrementally and not scraping the existing code (refactors are a very well known part of software development). It's also a great skill to have, which is a little bit separate from writing good code. Of course, make sure the requirements you're implementing are small and testable (mainly, but also see INVEST), so you can keep the refactors relatively small. Write unit tests for the requirement, refactor the code that implements it so that it's testable. And don't try to get it Right the first time, just make it better. You will have more opportunities.

Answer 8

My take on this.

Credibility: 2 yrs mixed experience in the same field.

Some facts:

1. You seem to be much better than the coder who was before you. (Probably he has spend a little more time then you in the company, or much more, I am unaware and hence he might have more of the "respect" you mentioned).
2. You can rewrite the whole code in some days. (let's just say with much much better quality).
3. Company has invested in you as well as him. Paid him for his work, is paying you for your work.
4. The other person took time to write the code and the company sees it as "an investment" and hence when you rewrote the code: they took it as an offense.

Correct me if I am wrong anywhere till here.

What I feel you could do (similar experience):

1. Assuming you understand the code base(fair assumption since you seem to be the correct front end guy), try to finish the requirements directly asked by the employer. (Without trying to touch the code which exists). Yes, this means, redo the common part (which I think should not be the same since you got new requirements). After you are done with the requirement, formally ask time to redo just a part of codebase (eventually finishing the whole code base according to your satisfaction).

2. You do your requirement and whenever you have to include a dependency from his components (make a choice, do you want to do option 1) if not, just use his component and "get the work done" cause at the end, the higher level management does not really care about the "quality" since they are busy converting the requirements to money for us. I don't blame them.

3. You write test cases for his code, wherever it breaks (just do that part of fixing) and then continue with your requirement.

4. (Mentioned by others) redo the whole code base. There are many reasons I would say not to. For one, You are being paid to do "new work" not redo the "old work" and also do your "new work". Its the company's responsibility to have policies or practices in place for such issues (you have done your part by mentioning the problem, and gave a solution). But I think they do not trust/do not want to risk by asking you to redo the work and finish your requirement. Natural human tendency, still I will not blame them. It is possible that you might get stuck might not live up to your word which will also be a negative strike on your image.

I would suggest, stick with option 1: (normally it ends up with a new requirement instead of time to improve, but priority is priority). You are paid from the user getting the app, not how well we write the code ( it plays a factor in long run, like right now, but that is what the management should figure out, or be reminded for). Do not take the stress on yourself.

Some pointers I would like you to improve on (have an open mind while reading it)

• Try to improve your communication. Obviously you have a good communication skill, you explained a good daily developer's problem here. What I am trying to say is, you can become a better convincer.
• Think from other people's perspective:
  • Manager: I have an employee who is asking me permission to redo an old work and redo in 5 days, compared to "not being able" to do the new work 5 days.
  • The guy who wrote the code: He will rewrite that code and the news will spread and people will think less of me??
  • You: I want to make everything perfect! I will change the code and make it perfect.
  • User: When am I going to get my product? I paid for it!!!

The moment you come out of your thinking, you will discover much more issues in the same field and you will yourself probably learn to deal with it in a stress free way.

I think these options are based on my experiences, however, do not completely be dependent on them, just take them into consideration, I do not want to be responsible for your future if things go south.

P.S. I had a payment repository to be dependent on :) I did not redo it. (Not my problem :)

Answer 9

You need to remember that your company is trying to solve a set of business problems, and the technical work is merely there to solve the business problems. What you need to do is work with your managers to weigh the short- and long-term business effects of working with the existing code as best you can versus rewriting parts or all of the code now.

You mention that you have a much cleaner version that delivers 80% of the functionality. What you've not mentioned are the business consequences of delivering only 80% of the functionality by the deadline, nor have you mentioned what the business benefits are in the longer term of having cleaner code. If, for example, the customers would be quite upset by the missing 20% of the functionality and the project is unlikely to be greatly modified after that (whether due to requests for feature changes or requests for bug fixes) it would be quite sensible, from a business point of view, to deliver what you've got from the original code and not worry too much about the expense of future changes.

The effects of making the code better now versus better later or never better are of course judgement calls. But without showing that you understand the business effects of the various options, your judgement on this is unlikely to be trusted.

I would work to do what you can now to understand the business issues and communicate to management a technical plan for doing what's best for the business in the short and long term. But I suspect that you've not convinced management at the moment that you understand the business issues and have the best results for the business in mind. Given that it may take some time to build up this trust, even if you think you are right in your current (apparent) analysis that a full rewrite is the best thing for the business, doing the best you can with the current code and working to build this trust (by showing you are working on the business problems, and not just the code) over time may be your best path forward.

Also, make sure that you understand (and show management that you understand) that this particular code being bad does not mean that the person who produced it is a bad developer. Typically developers thrown into an area where they have less understanding of how things work will produce sub-optimal code; that's an indication of a lack of knowledge about and experience in a particular area, not that they're simply poor at their job.

Answer 10

Rewrite

There are already numerous answers, but almost all of them say: "Suck it up." So I will offer the contrarian advice: go with your gut. As a back-end developer, I have a healthy respect for the entire different skill set of working with the front-end. I myself would never write front-end code except with a gun pointed to my head. I certainly would not tell a front-end dev that my version was "good" or even "good enough". If they offered to rewrite it in a week using best practices, I would say: "You're my new best friend."

It is better to ask forgiveness than to ask permission.

This is a bold principle to live by, and it may eventually lead to your [professional] death. But in many cases, it works. The key is that you have to deliver results. At the end of the day, nobody actually cares whether the code is good or not other than you. They only care whether they get to claim credit for the business deliverables. As long as they push buttons and the site does what they expect, they couldn't care less how it is powered. Most likely, the former dev has already forgotten about the code and would be happy to never touch it again. The other devs likely just suck up to the senior because it's good for their careers.

Strategy

Obviously, you need to maintain 100% of existing functionality. Do not break anything that already works, or you will be asking for a lot more than forgiveness. Otherwise, replace every bad bit you can possibly get away with, even if that means pushing the deadline a bit. You will really win points if you can add robustness or even functionality to your rewrite. Hopefully, you can identify some edge cases that the old code blows up on, and document repros for it as unit tests (which you check in). Then, you fix them with your refactoring.

Don't tell anyone you are doing all this. The managers who would tell you to stop don't know enough about code to have good judgment. The devs who can tell what you are doing don't have good enough judgment to recognize bad code. In the end, all that matters are the business results. If the other devs who have to work in your codebase say something, ask them if your version is better or worse than the old version. If they say it's better, then their job got easier and you have a new ally. If they say it's worse, ask them to explain why, but don't argue with them. Instead, drill down into each reason and make them justify it with technical arguments, rather than style points or "That's how we always did it." Always lead by asking questions, and think about the scenarios which make their version less desirable.

Security

Most likely, the existing code is riddled with security vulnerabilities. Try to find a few, and document those, especially if you can point directly to OWASP principles that are being violated. If you have contacts inside your client orgs, see if you can get direct feedback from them, especially on the aesthetics. Old non-techy folks can have embarrassingly high tolerance for ugly and difficult UIs. Sometimes you need a younger person who has used good UIs and has high expectations to tell them that their product sux. If you can gather a few emails from such client reps praising your redesign, that will speak louder than any other voice in your company. That will essentially be a veto of anyone who tries to challenge your strategy. But don't pull them out unless you are actually challenged. Hold all your cards close to your vest until you need to play them.

Manage Upwards

When you are finally forced to discuss matters with your boss, go into your meeting prepared. First, be prepared that your boss punishes you severely or fires you. If you absolutely cannot afford to get fired, then don't go this route at all. If you think you can find another job fairly easily (hard to think otherwise in this market), then this risk is likely worth taking. You have to make that call yourself.

Tell your boss that you are trying to help the team win, and if they play it right, they can take a lot of credit for delivering a much-improved project. You need to make it clear that your boss should take credit for making the product look better, and explain to their peers/boss that they also directed you to refactor the code to current industry best practices because it improves your feature velocity. As your boss tries to call BS on you, interrupt them and point out how smart they will look for delivering a superior product that goes above and beyond the bare-bones requirements, and pays down technical debt at the same time. If your boss doesn't know what tech debt is, give them a tutorial so they can then go and school their peers and pump their status in the org.

Everything you say needs to be a selling point that your boss can use in meetings with peers and their boss to angle for bonuses/raises/promotions. You need to sell your improvements as something that they can resell at a personal markup. And if all that fails to move them, pull out the emails from the client peers praising the improved UI. Then say: "Look, I know I pulled the trigger on these changes, and I'm totally ready to roll them back. But, uh...some clients already know what's coming down the pipeline, and they might ask some hard questions if we just deliver more of the old UI. So...tell me when you want me to hit the rollback button, and I'd be happy to do so. And in your mind, just say: "Checkmate!"

Then make some notes in your personal journal reminding yourself how you took the initiative to improve the UI and the codebase while delivering all the business asks when you have your next major performance review. At that time, ask for a bonus/raise if that's appropriate for your delivered work.

Answer 11

Will it take you any longer to complete your assigned work with the bad code than to refactor it and then complete your assigned work? Without knowledge of your codebase, I would guess the answer is "yes." The more well-organized and sensical the code is, the less time is needed to learn and reason about it and work with it.

Note: Just because you don't like it, doesn't mean it should be changed. Now, if you know for a fact that the other developer violated widely-accepted best practices for front-end development, then you may have a strong case for a rewrite.

Answer 12

What you should do / should have done:

Estimate how long it takes you to get an acceptable product with no refactoring / the bare minimum of refactoring / full refactoring, then estimate how long it takes to get a product in acceptable condition (possibly after the deadline) in the most effective way.

Since there is a deadline, "acceptable" quality is whatever is just barely good enough to meet the deadline.

If you can't get the quality you want within the deadline, something must give: Either the quality, or the deadline. That's where you talk to your manager, make him aware of the facts, and find out how important the deadline is. Your boss might say "If you can't meet the deadline, then last month would be your last salary. " Or they might say "exceeding the deadline by four weeks is kind of Ok, beyond that gets the company in trouble. "

Once you know the "real" deadline, you decide what you need to do to hit that deadline, without undue risks. There might be time between the deadline and the next deliverable to improve the code.

PS. Missing a deadline may cost your company significant money, because they signed some contract. Now it is possible that you have a deadline of March 31st, and if you deliver on that day with ten thousand bugs, your company doesn't have to pay for missing the deadline, while delivering on April 1st with no bugs is really, really expensive. It won't be that extreme in real life, but there are cases where deadlines have their own rules (yet in other cases they are completely meaningless). You need to know which before you can take any action.

Answer 13

Being an employee, as i see it, you have 2 options, go with it or leave. Companies occasionally get settled with specific set of tools and frameworks, and, for maintainability, do not want to add newer ones, that will require additional resources with new skill set.

Although, if you want to try something new, there is a third way.

Given that this is a front end and you are the only Front End Developer in the company, and if you have time - do what you need to do and make new UI in parallel.

When new one is done, replace the exiting from with your new one and keep going with the backlog.

According to your description, it will take some time until management will see the difference.

Be ready NOT to be congratulated when they catch on, thou :)

Answer 14

1. Do what you are told
2. Talk to the original developer and get the rest of the story
3. Look for another job

There is a unicorn fantasy in a lot of places that if you create something fast then you are "smart", filled with short-term thinking and elitism.

Ultimately you are not the only one that has had this disagreement with management, where are those leads now.

Making the case about DRY of GRASP etc. is part of that too. Instead, explain in terms of impact on the business in short term and long term capabilities.

CYA - record simple notes from each meeting, slow the discussion to write them down as you go, the shared screen on remote meetings works great. (Keep a copy at hand for when you get called in suddenly to explain yourself)

Don't take a side, make objective recommendations expressed in trade-offs.

But never blame another developer.

There are a lot of principles on how to create the one-true-software, stop believing them.

You said some of the clients are "big names". When the work has to be done in an impractical or technically impossible manner because the boss or client is "important" start googling "hostile working environment"

Answer 15

You totally took the wrong approach here.

If you refactored the code in only 2 days, you could have just finished the refactoring, deliver a better product, and still make the deadline.

You can always sell a refactoring as "improvement", i.e. "I improved the code - it's reactive now! :)"

This way you get what you want (technical improvements) and navigate the political terrain without upsetting anyone.

Answer 16

How much do you care about the job, and realistically how important is the feature? How much will you maintain it in the future? How accurate is your timeline for a total rewrite (a LOT of devs underestimate here, frequently by not understanding the real complexity of the code). In the end, there's 3 options:

1)Deal with it. This can be combined with a push to improve it in the future.

2)Partial rewrite. Refactor the parts you immediately have to touch to be better, and handle the rest as you have time.

3)Say screw it and do it anyway.

The less important the feature, the more pain dealing with the code will cause you, and the less you care about possibly losing the job, move down the list. The reverse, move up. Just realize that going to the total end is deciding that your future happiness is more important than the risk of being fired to you. Also be very realistic about what it will actually take and understand the code- quite frequently bad code is the result of the new guy not understanding why things were done, rather than actually being bad. That ugly hacky code could be subtle workarounds for 5 years of production issues.

In my career, I've done all 3. It really depends on the circumstance.