8 ms·

Ask HN: Started a new job and their existing code sucks. What to do?

• dylanhassinger 9y ago
  break off a tiny piece and fix it. then repeat
  • neilsimp1 9y ago
    This is really the only truly correct answer. Q: How do you eat an elephant? A: One bite at a time.
    • riwasabi 9y ago
      haha that's true
    • kleer001 9y ago
      A: or in shake
• alexmorse 9y ago
  First is it a priority? What are the business goals you're trying to accomplish? Do you have the resources to hit the business goals while some are working on a rework? Pretty code doesn't make a good business. Talk to your boss. If you feel strongly it needs to be done, explain why, and what the benefits are. You need to be able to quantify and qualify this so do your homework and sell it. Contrived example: Hey Manager, we've broken this experience 12 times in the last year, so I'm writing unit tests for it, so we can't do it again without knowing. It will take me an extra few hours on this issue but the payoff should be worth it. I think we should do this for everything. In the meantime, leave everything you touch better than when you opened it. Start teaching the practices you want to see.
• gus_massa 9y ago
  I recommend the classic "Getting Things Done When You’re Only a Grunt" ´https://www.joelonsoftware.com/2001/12/25/getting-things-done-when-youre-only-a-grunt/ https://www.joelonsoftware.com/2001/12/25/getting-things-don...
• saluki 9y ago
  Maybe you've been lucky so far working with good code. Most code is like this, it's semi-painful to work in. Once you have been working on it a while you'll be more used to it. I would spin it more like this. Hey if we refactor/rewrite this we can improve it and knock out these bugs in the process. It may be hard to convince the company to spend money on refactoring let alone writing tests. But you can always ask in a positive way to start on parts of it. You get paid the same, be positive, fix bugs/issues, improve things where you can. Keep making positive suggestions. As a developer you're almost always going to feel the urge to rewrite every app from scratch. I expect the code is making them money and they just want to keep things moving for now. At some point there is usually a rewrite from scratch, maybe that can be your project. Good luck with your new gig.
• bloat 9y ago
  I would try and clean up the bits I was working on. This is a good book on the topic refactoring a large code base with no tests. https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-...
  • riwasabi 9y ago
    Thanks for the tip! I'm gonna have a look at it. :)
• tmaly 9y ago
  I would recommend building out better tests for the system before you attempt to refactor it. This way you will have some better assurances when you change things. There is a great book on Legacy Code by Michael Feathers that I would also recommend.
• pascalxus 9y ago
  You gotta understand that this is pretty much the case at a LOT of places. In the beginning, you should be humble, at least for the first few years. Once you're the most senior person there, say in 5 years, you'll have a lot more political power to do the things you think are right. And as far as refactoring goes, take things 1 part at a time. Don't try to refactor everything all at once.
  • borplk 9y ago
    Few people stay that long in a company nowadays.
• marenkay 9y ago
  Be a little more relaxed about this. Legacy code often looks like a big elephant which needs lots of fixes. Look to the tiny things instead: - just make the function / class you're working on nicer, preferably just a small function. Apply some common quality standards to it, clean code, nice docs. - repeat this for a while, and you will have a nice set of examples and guidance for the other team members by setting an example. Personally I am a huge fan of making that one place where you found the bug nice, adding a simple test case and moving on to the next thing. It adds up over time and does not hurt in terms of time involvement/budget since you already had to invest a larger amount fo time to find the place bugging out.
  • riwasabi 9y ago
    "Be a little more relaxed about this" is probably the best advice haha. I think I just freaked out when I saw their code/had to debug it. But, as @pascalxus said, this is probably very common in many places.
    • marenkay 9y ago
      It is much more common than decent code that just lets you iterate and implement good stuff. Also the lesson to take away: code like this is everywhere and often it powers the things you really do not want to be run by something like that. Considering that you will face this probably with your next employer again, deep breath and just enjoy the actual engineering work!
  • chatmasta 9y ago
    If there’s literally no structure in place for running tests, then OP cannot just add “a simple test case.” OP also needs to build the test runner. That requires convincing his manager, who is likely the one responsible for this mess (by claiming maintainable code is not a priority). Personally I think it’s irresponsible to hire new employees before having a maintainable project. It’s much easier to onboard employees and delegate to them when they have a safe dev environment and testable projects to break while they learn.
    • 9y ago
• icedchai 9y ago
  Sounds normal. How many jobs have you had previously?
  • riwasabi 9y ago
    This is the fourth company I work for (not counting some freelancing).
  • unquietcode 9y ago
    It's so normal that I'm actively looking for a new career. I'm tired of being paid to write and maintain garbage code for garbage people.
    • romanovcode 9y ago
      You're not special yourself. People think same about you and your code.
• forinti 9y ago
  Code is not that important (most of the time), but documentation is always important (if all else fails, you can always rewrite). So, if it's not documented: write some use cases and draw some UML).
• cheshireoctopus 9y ago
  I find the Boy Scout Rule to be helpful: > The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it." > What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result? http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule http://programmer.97things.oreilly.com/wiki/index.php/The_Bo... Apply it as you go. Piece by piece. Perhaps encourage your fellow developers to adopt the practice.
  • DoofusOfDeath 9y ago
    > No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result? People would stop being willing to review his PRs, because they'd always contain off-topic changes?
    • lolsal 9y ago
      Being a good source steward seems to always be 'on-topic'. The only time I've seen gentle improvements rejected is during hotfix releases.
  • oldsklgdfth 9y ago
    I think about this every time I look at a piece of code that does nothing. I mean after I think of smashing my screen in.
• DoubleGlazing 9y ago
  There is no one magic bullet to deal with such a problem. Instead there are several things you can do in parallel to help. Whichever of these works for you depends on the industry and age of the company you are in. If the company is fairly new, then bad code is kind of expected. There is a rush to get a product out the door, so shortcuts are taken. Given time for things to settle v2 will be better. If its an established company or the code is legacy you can fix little bits as you go along. If documentation is lacking, write some - maybe even set up a wiki and bug tracking system if need be. If comments are lacking add some. If you can demonstrate the bad code is costing the company more in man hours (and therefore money), then maybe propose a a series of refactoring projects in order to help improve the code and increase efficiency. I worked at a company that would have refactoring parties once a month with pizza and chipper. On the last Friday afternoon of the month we would review 10 random code files changed in the last month and tidy messy code, add comments, docs, unit test etc. Suggest the company adopt some coding standards if they already haven't. Ditto code reviews and unit testing. Of course not all companies are receptive to such changes. Some take the view that if the product works, why wasted time on frivolous extra like docs and code reviews. Sometimes when the code has been primarily the work of one person they might not take kindly to criticism - even if valid. In those cases all you can do is just do is to write your own code as best you can and not worry about what goes on around you. Bad code is a lot more common than you expect and life is easier when you accept that.
• chatmasta 9y ago
  Consider the fact that you just joined the company, and are likely unaware of many complexities, dependencies, and edge cases that the code must account for. I suggest working with the code a bit longer before you make such bold proclamations as to its quality. Also consider your teammates built that code. How do you think they felt when you told them it needs a whole refactoring? Since you cannot refactor it in secret, you would need to get your manager’s approval to take on such a project. He is going to ask your teammates, who built the code and whom he’s known longer than you, for their opinions. So it’s important to have their support in refactoring. It seems like a needless risk. You have a low chance of success (first, convincing your manager, and second, successfully refactoring the code), but a high chance of loss (alienating your teammates).
  • afarrell 9y ago
    > likely unaware of many complexities, dependencies, and edge cases that the code must account for All of this argues in favor of having an overall architecture that can help a team member grasp these complexities. Maybe there is one that OP cannot see. However, edge cases also cry out for automated tests. Whether or not a codebase has automated tests is explicitly clear from the first day. > So it's important to have their support in refactoring This is absolutely true. A software team is made of people and trying to drive change without respecting people's need to be persuaded is both rude and doomed to failure. That persuasion is hard and I wish I had better advice for OP than to read books by the Harvard Negotiation Project. > How do you think they felt when you told them it needs a whole refactoring? Depends on the teammates. I've built a codebase that was a pile of spaghetti before and I felt terrible about it and left. So there may be people who agree with OP that the codebase needs significant improvement. There may be other people who, in the style of https://danluu.com/wat/ https://danluu.com/wat/, never imagined that things could be better. But one thing that the current teammates have in common is that they all have not left. The people who care most about clean code are the people who self-selected out of the team already. > It seems like a needless risk. So is making any change to the codebase without tests.
• GoToRO 9y ago
  If you can find a better place, get out. It's one thing that the code is bad, it's another that they just don't care. Now you know what question to ask during the interview...
• psyc 9y ago
  Refactoring is almost never a priority at a real company that has brought a product to market. Either the culture there is receptive to it, or you're better off learning to live with it. Sometimes you can get away with small, incremental refactors of things that touch the new code you check in.
• kleer001 9y ago
  > they acknowledge that some refactoring is necessary, they don't think that's a priority (and that we should focus on bug fixing) Sounds like they're more interested in make-work and job security than creating a good product. You may wanna get out of there.
• drspacemonkey 9y ago
  About 2 years ago, I was in the same position as you. Had been freelancing for years, then went back to full-time employment. It was quite a change from what I was used to. IE: working with a very small team of people I chose and have worked with before. A lot of the advice I've seen here relies on the rest of the team wanting things to get better. That's not always the case. Many teams are very proud of their unmaintanable, untestable spaghetti. Some see it as a of badge of honour that nobody else can figure out something as basic as where model validation happens (in that specific case, they marshalled all their model validation into the controller parent class, and things got worse from there). So the first thing you need to do is figure out how open they are to changing. If they're happy with what they've got, and they don't want to change how they write code, then there's not much you can do. Cleaning as you go is a great idea. But even if there's only one other person on the team and and they don't want to change anything, they'll be generating mess twice as fast as you can clean (making a mess is always faster than cleaning). That's my advice. Try to probe if they're willing to admit they even have a problem. Start with floating the idea of writing tests, or implementing a style guide. If they don't even want to do that, there's no way you're gonna get anything bigger out of them. At that point, you gotta decide if this job is right for you.
• deleted 9y ago
  [deleted]
• Nomentatus 9y ago
  Here's the idealistic answer: see if you can get a very private interview with the head of the company; even the board of directors. You are accepting money, so you actually have an obligation to get this information to them. Doesn't mean you'll be believed necessarily, and yes it's high risk but the obligation is there and the reward - the difference you'd be making if the ship can be turned around - is large. Of course, the other side of the argument is that it's not unlikely the head of the company is the guy who created this problem, so maybe looking up one of the board of directors, or an investor, is a better idea.
  • elf25 9y ago
    oh no way do this until you've been there many months.
  • Terr_ 9y ago
    > very private interview with the head of the company; even the board of directors Are you assuming that OP works in a small SV startup? Most jobs are in companies where that isn't plausible.
    • Nomentatus 9y ago
      I'm not assuming the original investor wasn't the owner/proprietor, but I mention the possibility. I do assume a board, if that's not present, bail.
      • Terr_ 9y ago
        * whooooosh * OP did not say a single thing about the size of the company, nor anything to suggest that they have been hired in a significant management role. It's entirely possible that they're going into a junior role in Amazon for all we know. Your replies, in contrast, don't even admit those extremely-common possibilities, and I find that omission baffling. So, confused, I'm trying to think of explanations, such as that all your experience has been with smaller companies... or that were your born into upper-management Jeff Bezos is a golf acquaintance.
• fapi1974 9y ago
  I just wrote a book on startups that touches on tech debt, and in your shoes I wouldn't freak out. All startups/companies acquire tech debt until they really find product market fit and something I call GTM fit. At some point you have to go back and fix it, but until your business trajectory is clear refactoring can be the wrong allocation of resources.
• microtherion 9y ago
  First at all, something akin to Chesterton's fence applies. Somebody new to an organization rarely understands all the factors that go into a code base, and even if they're right that the code base is bad, they are generally not yet equipped to safely fix it. Second, this might be a first for you, but a new person coming in and deciding that the current code base is unsalvageable and needs to be completely rewritten is pretty much a cliché in our industry. So what would I do? Like cheshireoctopus said, you can leave each bit of code you touch a bit cleaner than you encountered it. You can also try to get approval to start writing tests — having a test suite in place will first help you understand the existing code through and through, and then provide a safety net once you get around to proceeding to the actual refactor.
  • mythrwy 9y ago
    I agree but sometimes the whole thing is so clown shoes from the ground up it just plain isn't going to work as is. That does happen.
    • jf22 9y ago
      Its obviously working if the company is hiring right?
  • atmosx 9y ago
    > Second, this might be a first for you, but a new person coming in and deciding that the current code base is unsalvageable and needs to be completely rewritten is pretty much a cliché in our industry. Amen.
• tibbon 9y ago
  Been there. One of my more-recent companies was like this. So few tests, 200+ line methods, no style guides, etc. The problem isn't going to be the code - you can fix that. It's if management is actually ok with things changing. So often there's resistance to change for a variety of reasons, some good - some bad. Bad ones include "it's too hard" or "Well, this guy wrote it this way and we don't want to hurt his feelings". At least they are into bug fixing. I've been at companies that were feature-focused 99% of the time, because the CEO and VP of Product had overpromised so much to clients and investors that we were always chasing some overly ambitious fairy tale. Quantity ruled over quality. When things broke or didn't scale, they acted like they had no idea why. It was always more more more. These situations are the ones that can't be fixed. Run as fast as you can. But, if they are amenable to getting a plan in place and working on this stuff slowly, then it surely can be fixed. Bug fixing is important though, as I don't want to try to refactor broken code, only to break it more.
• agitator 9y ago
  "It's almost an Italian restaurant" made me crack up. I had the same problem when I started working at a startup a few years back. The code base was a spaghetti factory, but that was the least of the problems. No one was prioritizing issues properly, management was aloof, the bugs being discussed in the product were huge oversights, deadlines were looming, but nothing about the trajectory was indicating that anything would be met. I left after a week, a year later, they went out of business. So I guess the take away is, if it's just code, being new, you will always run into differences, poor code (maybe there were reasons for quickly scrambled code), oddities, but don't let that throw you off, maybe they need more people so they don't need to scramble so hard? Bringing it up, or butting heads will only keep you from progressing. If you want to stick it out, assimilate and just prove yourself through superior code/work ethic. But if the code is a symptom of a much bigger mess in the company, then maybe look for something else? It's tough, and we would really need to be there to understand the whole situation.
• NeverYouMind 9y ago
  I found myself in a similar situation recently. This may give you something to think about... http://thecodelesscode.com/case/33 http://thecodelesscode.com/case/33 You might want to do some reading of books about how to promote institutional change from within. If you can read, and then get your manager to read, "Creating a Software Engineering Culture" by Karl Wiegers, that might help. Also, "Refactoring" by Martin Fowler is highly advised. Regardless, maintaining good relationships with your coworkers, and specifically your manager is key. One key insight I have gathered over the years is that whenever possible, there are benefits to avoiding telling someone "this is a problem/bad/whatever and needs to be fixed" if it is instead possible to say "That's great, and it would be even better if..." The criticism in the first form invokes a immediate defensive reaction once someone hears "this is a problem" which may cause them to not hear whatever you say next, and can create a teacher vs. student dynamic (see Pavlov's work on negative conditioning) in which they may actively start to resist your suggestions, while the second form is more likely to cause them to feel good at having been praised and want to seek further approval (positive conditioning, which tends to be much more effective and produce more long-lasting behavior changes in most circumstances). Some research on self-serving bias suggests that people are much more likely to believe what you are telling them if you can phrase it in a way such that it sounds like praise. Good luck!
• deleted 9y ago
  [deleted]
• gshakir 9y ago
  Do you the like the new job (except for the code base) ? Like the domain, co-workers etc. If so then propose that you can increase the velocity of release by proposing good architecture practices. Then have them write integration tests for all the major test cases and start peeling the layers. It is almost kind of fun to develop in brown field instead of green field. Looks like the code grew organically without much thought.
• echlebek 9y ago
  I'm not sure why nobody else has said this yet, but go find another job and then quit. There's no reason that a good developer should have to toil away in obscurity on a shitty codebase.
  • riwasabi 9y ago
    I'm here for only a week but I must admit I think about quitting. I could always go back to my previous job (I only left because it's a bigger company and much higher salary). The only problem is that I moved to a different country and I signed one-year contracts (work, housing, etc.), so I'd ended up paying a lot of fines for breaking them.
    • deleted 9y ago
      [deleted]
• segmondy 9y ago
  You were hired to help fix the problem not add to it. No rewrites, no major refactors yet. Fix bugs, for every bugfix add a regression test so it never happens again. Find a list of the most recent bug fixes, findout if there is a common pattern. If so, target that. Are there code reviews? If not start one. Is there a coding standard? If not start one. With code review & standards in place. Start adding small tests. Small refactors with tests only. Are there things that need to be done in a specific order most of the time? Document it, build a checklist. Are there good logs? If not, add them. The difficult work right now is not technical but social. The team needs a good process and to follow a best standard. It's gonna be tough, cultures are difficult to change, but be patient and remind yourself. You were hired because they have problems not because they want to give away free money or help you out with a job.
  • mattmanser 9y ago
    What's the point of adding regression tests to spaghetti code? All you're doing is making it an even bigger pain in the ass to refactor. And at this stage he probably doesn't even properly understand the business logic behind the code anyway and will make duff tests. I'm admittedly pretty meh about tests, never seen good ones that are flexible and actually test the functionality instead of the implementation. One of my client's actually had a contractor add a bunch of tests to some existing code that took him a month or two and caught a whole one bug in 4 years that would have probably been caught in QA any way. Otherwise I generally agree, but you can refactor as you go, which I've done plenty of times. Depends on team size and how productive you are to the other devs, but you can single handedly refactor really bad sections and setup a general outline of how the code should be laid out within a year, though you need to start getting people on board.
    • mattm 9y ago
      > What's the point of adding regression tests to spaghetti code? All you're doing is making it an even bigger pain in the ass to refactor Refactoring is changing the code to make it more understandable while keeping the functionality the same. That is the perfect time to add tests. Adding tests before refactoring will help someone understand the code first and will also let you know if you've broken something.
• deepaksurti 9y ago
  >> No good practices are being followed, there are no tests, huge components that should be modularized, no organized architecture at all. I am not blaming you here, but it's our job to ask during the interview process a few questions from the Joel test. Then tell them just show me the systems, just one engineer opening up their Travis CI or any other dashboard, some git repo with test coverage number (no need to show code). If they don't show, don't join. >> Just don't care and keep doing what you're told to do If the earlier engineers on the team say so, most likely that's the way to go. May be striking conversations over coffee and try figure out if somebody else earlier tried to buy a refactor and it did not work. May be the management just does not care, then find a new gig if this is horrible. If it were lack of capability/experience, do some rough estimation and propose a refactor plan for every delivery, that is some critical pieces get refactored in each delivery. If this is also not acceptable, then seriously find a new job. Best! >> This is my first time starting a job with such a bad existing code, Well, and this may not be the last time; unfortunately this is how this circus works.
  • riwasabi 9y ago
    >> it's our job to ask during the interview process a few questions from the Joel test I know. That was totally amateur on my side. I was excited because it's a nice company and just accepted their offer. And they're nice guys. It's not like they're assholes but their mentality towards coding standards is frustrating. Anyway, at the end of the day, I know it's my fault for not asking those questions during the recruitment process. :(
• jitendrac 9y ago
  Just talk with your CTO(or person with similar post), arrange some meetings with lead developers and make list of some best practices and rules for structuring files. Move one or couple of steps a time, review it in action and move ahead. Don't go on rushing to change existing codebase, spaghetti code is not what company's customers/clients are concerned. They are concerned about the end results. Starting good code practice will make legacy codebase dwarf at some point.
• r-s 9y ago
  First step is to relax. You will see many codebases like this in your career, its not worth getting all worked up about. Slowly migrating a codebase like this to a good one will take a bunch of work, but its a worthwhile challenge. They are lucky to have someone that cares about code quality! I would do the job you are paid to do, fix github issues to the best of your ability. Leave the codebase in a better place then you found it. Include small refactors with your code, talk to the other devs frequently and find their pain points in the codebase and take stories which relate to those. Its 100% not worth it getting depressed feelings for a codebase. I once worked at a startup with a codebase so poor that its hard to explain. The first month I was in a panic because I had 0 clue how to work with it. After a year the team slowly got it to an "ok" state. The truth is that the lessons I learned on that job have been the most important of my career.
• minati_m 9y ago
  the technological public to purchase or influence the purchase of Red Hat JBoss Middleware Integration commodities & services. The JBoss Technology Evangelist will try to focus efforts towards results that are extremely leveraged, but may also be asked to help in more specific efforts such as helping close a particular customer. The JBoss Technology Evangelist has significant technical sales enablement charge and also helps influence JBoss Middleware product management by privately reporting demands and possibilities got through landscape and customer communications. For Joining online training batches please feel free to call or email us. Name: Minati Email: minati@maxmunus.com Skype id- training_maxmunus Contact No.-+9066638196/91-9738075708 For Joining online training batches please feel free to call or email us. Name: Minati Email: minati@maxmunus.com Skype id- training_maxmunus Contact No.-+9066638196/91-9738075708
• poletopole 9y ago
  I felt this way when I started my current job, and still do, ha. I even tried to rewrite the whole codebase. What ended up happening is that my code never saw the light of day because my coworkers are simple folk. You have to write code that the rest of your coworkers will be willing to work with, which is often shit code.
• minati_m 9y ago
  Really appreciated the information and please keep sharing, I would like to share some information regarding online training.Maxmunus Solutions is providing the best quality of this TABLEAU Technology And this online training will be very convenient for the learner.And the training will be online and very convenient for the learner. For Joining online training batches please feel free to call or email us. Email : minati@maxmunus.com Contact No.-+91-9066638196/91-9738075708