-1

A small, neglected project has recently been reported by users as having time out errors and some object reference exceptions. As I am a recent replacement for a developer who was responsible for this project, I didn't have the solution installed on my machine.

In the process of trying to get a local build to run, I'm finding that several referenced Nuget packages are deprecated so the solution fails to build. At this morning's standup, I mentioned to the team that I am hunting for the deprecated packages so that I can debug locally, or at least attach a debugger to QA/Prod, and then will continue to investigate the issues. A coworker who is sort of "handing off" the project chimed in that they got it to build locally by updating the local solution from .NET 3.5 to .NET 4.5 and upgrading to new Nuget packages.

I thank them for their remark and retorted that I am trying to debug some immediate issues on production so I'd like to replicate the QA and Production environments as closely as I can; their response was one of pure confusion and protest. I explained that production has many user-reported errors, not including those being logged by the server's reporting mechanisms, and that I didn't want to add more fuel to the fire by upgrading the solution's framework. The colleague replied that they don't suggest I upgrade production, just the local build, and debug that way.

This goes against everything my mentors and senior engineers have taught me about having local builds as close to production as possible, and to me, that has always been sensible advice. Am I being too hard-headed here? If you think the code fix won't be framework dependent, should you just do whatever you can to quickly get a build running to debug?

Improve this question
6
  • How is the production team maintaining the software if it won't build? Commented Oct 4, 2019 at 19:12
  • 2
    In any case, I don't see how you can meaningfully debug a production system if your build isn't the same software. That's too much variability to contend with. Commented Oct 4, 2019 at 19:13
  • @RobertHarvey The production "team" consisted of the developer I replaced and a backup developer. I have no clue how the original developer was maintaining this solution- I would have assumed s/he'd of included the deprecated Nuget packages in the repository but they did not. From digging in server logs, this project has been neglected. Commented Oct 4, 2019 at 19:18
  • 1
    When debugging an application with a different baseline, visual studio cannot enforce breakpoints. You have to wait for the app to throw an unhandled exception before execution stops. It really only takes a couple lines difference in one file to be in that bad place. The best you can do is debug the local version that you built. At that point it's a new baseline so if you fix something then production will have to be updated to your new baseline. Commented Oct 4, 2019 at 19:26
  • Following the candied_orange answer down there - do you have the plan how you would deliver your future fix without migrating the production to newer dependencies? Commented Oct 5, 2019 at 11:34

3 Answers 3

Reset to default
1

A small, neglected project is finally getting some attention. Why the hell aren't you upgrading production? It's just one bug? No it's a neglected project that no one wants to touch because it's a neglected project.

If you kill yourself figuring out how to maintain the neglect you might just fix the bug that's been found. Then you and everyone else will go back to ignoring this because you've done nothing to make the situation better.

I'm not suggesting a rewrite. Just a new version that works with the latest stuff. That might be a deal breaker in this codebase if things are bad enough that it's effectively a rewrite but if it's not why they hell aren't you doing it? Ignoring this problem just makes it worse.

Software is meant to be soft. It should accept change. Don't let it rot until it can't.

Now all that said, it's a heck of a lot easier to upgrade the old to the new when you have a working version of the old to play with.

And yes, don't let go of the idea of having at least one dev build that mirrors current production. But delivering a whole new version "just for one bug" is not a bad thing. It sounds like it's past time to do it, bug or no bug.

Improve this answer
8
  • Maybe Im confused but from you answer, it sounds to me like you think upgrading production is what this question is about. Trust me- as the new dev for this project, I plan on doing that. But -- I do not believe in upgrading a production solution from, say 3.5 to 4.5, when the server is RIDDLED with critical event errors and users are getting flying exceptions. Which is why I'd like to solve those bugs first. Debugging is usually done locally, no? And thus the question "Is it wise to locally debugging a solution with a framework version that differs from production's?" Commented Oct 5, 2019 at 1:34
  • 8protons I'm making the answer about upgrading production because you need to be thinking about it now. Solving bugs that you might be eliminating anyway is a distraction. What you need from the old code more than anything is a clear picture of what this thing does now. The only reason I'd bother with getting the existing version working locally is to get that clear picture. When you upgrade it you're in for a whole new set of bugs. If you fix every bug before upgrading it you'll never upgrade it. Commented Oct 5, 2019 at 1:39
  • Most of the solutions that I've worked on that have gone from a major upgrade (X.m -> Y.m, not X.m -> X.n) immediately had bugs and errors that would need to be resolved. Don't you think it would be wise to solve the existing issues in a stable environment as opposed to changing up that environment and very likely introducing more chaos to the mix? Commented Oct 5, 2019 at 1:41
  • Yes, you will have bugs that will need to be resolved. This will always be true. The main thing is getting a clear picture of what it does now so that you know what upgrading changes and can see what those new bugs are. I'd keep keep each upgrade as minor as I could. Fixing the annoying bug isn't about the bug as much as you getting your feet wet in the code base and showing progress. That keeps you going but it's not doing the project that much good. While you're in there, lay the groundwork for getting the project up to date and keep it that way. Commented Oct 5, 2019 at 1:55
  • Yeah exactly my point... so wouldn’t you just try and find the deprecated nugget packages so you can run the local 3.5 build and thus now match production? Which is also 3.5? Did I explain something poorly Commented Oct 5, 2019 at 1:56
0

Well, the suggestions you seeking here will be entirely opinion based. However not all opinions need be different. So here is what I have learnt in the past few years.

We are in the company to make check-ins, make deliveries because that is the only way our companies can make money. The rest is secondary. The next thing is deliver as quickly as possible. Of course that doesn't let you to skip quality checks, no, but that means you must deliver by doing the minimum that meats all checks and fixes the problem.

Now coming to your case, as it's an issue from the customer it must be fixed as quickly as possible. If you can reproduce the issue in the existing setup then that is the best case. Because upgrading/downgrading your entire setup is a separate task which will have its own challenges. Hence you should consider that only if all the other options are proven failed and not as the first step.

Improve this answer
7
  • 1
    How do you propose to deliver working software to the customer? Commented Oct 4, 2019 at 19:20
  • OP already mentions that the development systems have one working version of the setup and the build server has the other version. Both are working versions. So there should not be any issues in merging a particular change from 1 setup to the other Commented Oct 4, 2019 at 19:23
  • So you say. But I wouldn't rely on that unless there's a reliable build system in place for the original version, and there's no evidence that's the case. Commented Oct 4, 2019 at 19:25
  • If that weren't the case, then how will the team deliver the patch? Otherwise they will have to deliver an entirely new software just for this 1 bug Commented Oct 4, 2019 at 19:27
  • 1
    Agreed unless he can build the 3.5 version he can’t deploy any fix without an framework upgrade! Commented Oct 4, 2019 at 19:32
0

I cannot tell if upgrading to the newest framework version is worth taking the risk or not, since it depends a lot on the external packages involved (my experience with .NET framework updates from 3.5 to 4.x was that it went always smooth, since Microsoft cares a lot about backwards compatibility, but YMMV).

But what I can tell you is, you and your colleague both seem to miss an important point: if you start debugging in a local environment with a newer framework version, you may still be able to find issues and fix them. But what next? If you can only compile your fixed program against a newer framework version, and don't take the time to find the deprecated Nuget packages, the next version you deliver to production is necessarily a version linked against the newer framework.

So the suggestion "not to upgrade production, just the local build, and debug that way" makes no sense - if your start debugging, the next step is deployment, and if your local build works only with the newer framework, your next deployment will upgrade production. You cannot have your cake and eat it.

Let me add one thing. You wrote

This goes against everything my mentors and senior engineers have taught me about having local builds as close to production as possible, and to me, that has always been sensible advice.

Sticking to principles just for the sake of principles (or because some of your teachers have told you something) is the opposite of being pragmatic and won't make your customer happy. Trying to find pragmatic solutions, even if they break some of the principles someone has told you in the past, is a good approach in general.

In this case, however, there are hard facts why you should have your dev environment as well as your prod environment in sync, so focus on that, either by "downgrading dev" or "upgrading prod".

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.