4

I am a software engineer.

About 7 years ago, I started my first job out of college at Alpha Inc. (fake name, to protect the innocent). Alpha Inc. was in what my mentor called the "large startup" phase; the company had about 50 employees and a handful of products that it sold to customers around the world (some of these customers being large government entities). Over the course of 5 years, I was mostly relegated to two specific products, while other engineers took care of the others in their own teams. Over the course of these 5 years, the company continued to grow, and my team of about 5 engineers fluctuated over time to sizes in excess of 30 engineers.

About 2 years ago, Alpha Inc. was bought out by Gamma Inc. (again, a fake name). This was extremely out of the blue and caught many in the company by surprise. Basically over night, half of my department filed their resignations, and as their retirements were implemented, I suddenly became the single most senior individual remaining in Alpha Inc.. Of those who didn't quit, only about 5 engineers were actually retained by Gamma Inc. post-acquisition, myself among them. Our team basically shrunk to about a fifth its size over the course of those two months.

Gamma's employee base was roughly 5x that of Alpha's at Alpha's height. It is also located on the other side of the country (USA) and they terminated the lease on our office and instructed us all to become remote workers.

After Gamma had officially absorbed Alpha, Gamma started enacting plans to incorporate our work into their systems and business model. Both of the products that I had worked on for years were cancelled and eventually sunset from our customer base because Gamma already had similar products in place and a business model that allowed them to make more money off of those products than what Alpha had created. So, all of the work that I had been responsible for up to "The Acquisition" was effectively thrown in the trash can. I would tell myself "Well, whatever, this is business and that's life, I guess," whenever I though about how I should feel about it.

That left me in a position where I had to adapt to products that I had never worked with before. As I started working on my ex-colleagues' code, I quickly came to the realization that their standards for quality and correctness were leagues behind those enforced in my old projects. This isn't a software engineering board, so I'll summarize it like this: the code I had inherited was crap. It's buggy, has many embarrassing technical limitations, and is very hard to maintain. Also, since almost all of the people who had worked on this code had scattered to the winds at the time of The Acquisition, I've basically been flying solo through this endeavor.

What I've discovered is that, in addition to inheriting the code for these products, I've also inherited my new coworkers' ire for how poor the code is. They often express curiosity in such questions as "Why was it allowed to get this bad?" and complaints about production downtime and maintenance windows being too long. I've been doing my best to redo that which was done poorly, but there's so much of it (several million lines) and only a grand total of two engineers in the company (including myself) who officially know the programming language used (Java), so it is very much an uphill battle.

I've done my best to shrug off the complaints and to keep on trudging through the muck, but then one day recently, there was a particularly bad production outage that affected an extremely big customer for about 12 hours. Our contracts obligated us to give them a free month of software usage as restitution for the outage, which amounts to tens of thousands of dollars of yielded revenue. Gamma Inc is currently a multi-billion-dollar company, but still, not a good day for us. At this point, my boss came to me and expressed his disappointment in our team's ability to create dependable code and--when I tried to explain that it was something that Alpha's engineers had created that caused the outage--he fired back with the threat of "renegotiating" my salary if it ever happened again, which could be disasterous since my current salary barely even covers rent and basic daily goods (thanks, Housing Market). Suddenly, the crap I had inherited and the frustrations that my new coworkers had with it were more than a cloud on the wind that I could shrug off: the quality of my ex-colleagues' work could have a very real negative impact on my career.

I've tried to express to my new colleagues that, had I actually been in a capacity to work on these products in my time at Alpha, I wouldn't have allowed them to get into such a state of disrepair. But, putting myself in my coworkers' shoes, I can see that there is little worth in throwing my ex-colleagues under the bus & that it certainly doesn't help the business' bottom line. I have also suggested that we would be better off if we re-created the projects from scratch, but those suggestions are always shot down, stating that it is unacceptable for my team to go dark for several months at a time rewriting a product that's already on the market, no matter how much better the outcome might be in terms of quality.

I'm feeling frustrated and a bit lost. How should I best handle this scenario?

2
  • 10
    You developed a product, and learned a new codebase since? Now your boss is holding you to blame for the people he used to manage? I think your boss just "renegotiated" you into getting your resume together and looking for company Delta (change). Sep 19, 2017 at 0:27
  • "threat of "renegotiating" my salary" = we're not good enough to manage this. Hello Super CV Maker Gold Edition+!
    – DTRT
    Sep 19, 2017 at 18:54

5 Answers 5

12

At this point, my boss came to me and expressed his disappointment in our team's ability to create dependable code and--when I tried to explain that it was something that Alpha's engineers had created that caused the outage--he fired back with the threat of "renegotiating" my salary if it ever happened again...

I'm feeling frustrated and a bit lost. How should I best handle this scenario?

You should find a quiet time to discuss this with your boss.

Try not to be defensive; just be factual.

Explain how the code base came to be. Explain how you ended up being left to maintain it. Explain how you have been doing what your boss told you to do, and how that didn't include rewriting the code to make it better.

You don't need to throw anyone under the bus. You don't need to take responsibility for the quality of the code. You do need to express concern that going forward the quality of the code could indeed cause problems to occur.

Then you can ask your boss what he would like you to do about it now.

If the boss is so unreasonable as to threaten your salary over the lack of quality in the code base, then you should immediately start looking for a new job while you do the best you can at this one.

Hopefully this was just a terribly poor way of the boss expressing frustration. Hopefully he will tell you that he understands that you aren't responsible, that he didn't mean what he said about your salary, and that he apologizes for his outburst.

In general, don't apologize or be defensive about something that was not of your doing.

5

Aside from considering whether you really want to work for a boss who talks to you like that, you may find it helps to continue avoiding derogatory comments about the old code base yourself. I'm not suggesting that this is your issue, just that there is a fine line to walk here and that a positive approach may be reflected by your colleagues and superiors.

If you haven't encountered the prime directive before then it is a statement used in agile retrospectives to get into a constructive frame of mind regarding past actions:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

I've used this frequently when dealing with older code bases with significant technical debt. The idea is to accept that the developers who wrote (now) legacy systems were probably not idiots after all, and that this is really about allowing technical debt to build up to significant levels over time. Focus on the technical debt and others will too; focus on shoddy work and that's what will be served up in all directions.

Having said this, if your manager really cannot comprehend that maintaining several million lines of technical-debt-ridden code with two engineers is an uphill struggle then you are definitely in trouble.

3

I might not have the same experience as you do, but it would appear that you have to make a decision regarding your employment:

Should I stay, or should I leave?

Unfortunately, this is a decision you'll have to make for yourself. But based on your statement of high housing costs, I would presume that you are either located in the San Francisco Bay Area or the New York, New Jersey, Connecticut Tri-State Area. Nevertheless, your location offers you advantages in finding another employer within traveling distance. Given your skillset and experience, you'll find yourself offers not before long.

If you decide to stay, be objective and lay things out as they are, you inherited a poor-code base. It will cost X in terms of time and manpower to conduct a thorough code-review. Chances are it won't immediately solve the problem, but you can implement procedures to reduce the likelihood of it happening again moving forward. Put it on the record that the decision to not review legacy code wasn't made by you but rather your superiors.

The next time it crashes and everyone starts to point fingers, you can know for a fact that a solution was proposed but not implemented.

5
  • 1
    There are anywhere from 11 to 76 "Tri-State Areas" in the US, depending on how you count.
    – aschepler
    Sep 19, 2017 at 1:24
  • Haha, noted and fixed.
    – Bluebird
    Sep 19, 2017 at 1:25
  • Given your skillset and experience, you'll find yourself offers not before long. +1
    – LeLetter
    Sep 19, 2017 at 18:48
  • @aschepler - I usually just assume it's the one that Dr Doofenshmirtz wants to conquer. Sep 19, 2017 at 20:23
  • Put it on the record that the decision to not review legacy code wasn't made by you but rather your superiors interesting = I'm in a similar situation. +1 Sep 20, 2017 at 20:21
2

There's a form of abuse (in employment and in relationships) where the abuser employs mixed messaging: bouncing back and forth between "Your work is terrible and you're going to fired for it" and "You are literally the only person in the world who can fix this for us" puts the employee is a 1-way codependent relationship with their employer. This is how extremely talented developers with years of experience in popular, challenging languages get stuck in dead-end jobs with terrible companies.

Everyone knows that the legacy code is trash, and yet only you and one other person can address it, as if no one else in the world knows Java, or can even learn it. They could have brought on more people, they could have hired contractors, they could have replaced those products, but they didn't, and now the code is becoming unmaintainable, and your boss is threatening to renegotiate your salary? After seven years of hard work with a highly-sought after skillset?

My advice to you is to start taking calls from recruiters. There are better companies out there with more interesting projects and managers who actually care of about their direct reports.

1
  • A-(freakin')-men! Sounds like OP is the "high road" kind of person, but the temptation to inform the boss that re-negotiations will not be necessary, along with a wish of best luck maintaining the product going forward when handing the resignation notice would probably be more than I could manage. In any case, even taking the high road, I'd let the boss know that the direct threats were the decisive factor in making the determination that the job is "thankless." OP did a great job in describing a scenario that made my blood boil. Sep 19, 2017 at 20:33
0

I would sit down and plan. Twice.

  1. Plan on a personal level what your goals are and how they align with the direction the company is moving.
  2. Take stock and work with managers on establishing priorities and what's elements of the system need work. Create a plan of getting to point B (the great thing is that you need to establish of what B is).

I've been doing my best to redo that which was done poorly strategy will only make the situation worse, because you actually will be the last person touching the code - which means you will be made responsible for all its shortcomings.

On a personal level, instead putting the blame on your shoulder, remember that you are your manager's best bet to improve things - you are the key. Don't forget that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .