3 ms·

I am currently firefighting for a customer who has a medium Sized application in c#. Started around 2019 so not ancient, but every programming, architecture and

by HdS84 3y ago

I am currently firefighting for a customer who has a medium Sized application in c#. Started around 2019 so not ancient, but every programming, architecture and technology choice was wrong. Sure it compiles. But often it crashes without rhyme or reason and for some reason, customers hate it. First thing I did was to get it from .net 4.8 to .net 7 and enable all available errors checkers and style linters. The other howled, but their builds stopped because they could no longer check-in crap. That helped. But fixing this is more work than what this would have needed if they had done it right the first time. Funny examples: reinvanted rabbitmw badly using raw TCP and XML. Better hope your network is good, If the messages arrive at the same time, they are merged and the app crashes. So there are lots of time.sleep(50) calls to avoid that. Why is that app slow? The iot devices can only address 254 states. The UI for that allows ulong devices. It's never checked, but if the vast fails, the app just crashes.

Shrezzing 3y ago
> First thing I did was to get it from .net 4.8 to .net 7 This might not have been a great idea, I'm fairly surprised nobody stopped you before you went through with it. 4.8 is the "final" version of .NET Framework. It's pretty much the longest "Long Term Support" offer Microsoft will ever give for a platform, realistically they'll be supporting it into 2030 and beyond. I'd not start any new projects in it, but upgrading away from it probably wouldn't be the first thing I'd do on a new project. From .NET5, the framework moved to fundamentally different approach. It's effectively a different framework with the same NET branding on it. Most organisations who decided to move from 4.X to 6.X went through a near total rewrite because the paradigm shift is so massive, lots of organisations decided to stick with the pre-5 versions. The architecture and technology choices probably make a lot more sense in the pre-5 version of .NET, and it's unsurprising that your colleagues are frustrated with this decision, irrespective of the quality of their code. On top of the move between .NET paradigms, you've moved away from a long-term-support version. NET7 is an 18month short-term-support interim release between two Long Term Support 36month versions .NET6 and .NET8. By moving to 7, you've trapped the company into an early & rapid upgrade path to .NET8 as soon as it comes out in Nov 2023, rather than giving the full 12 month buffer you'd have got if you moved to .NET6, which is in Long Term Support until Nov 2024. You moved the application off of a rock-solid framework with near infinite long-term-support, onto a framework that'll be deprecated before in four months, and out of support entirely in ten. If I were you, I'd probably not be bringing this decision up in any performance reviews or interviews at new companies.
- HdS84 3y ago
  I honestly do not get what's your problem. We moved from 4.8 to 7 because a) the better compiler warnings helped to reduce the amount of shit people where able to check-in AND highlight problems in the existing codebase (beyond "well, it looks like written by the lowest bidder offshore guy drunken on Friday night") and provide management with metrics they could understand (two warnings per LOC is part of your problem). B) it deepened our hiring pool, because it's easier to find people willing to work with current technologies than legacy. C) it allowed us to pull in various modern libraries (BLe especially) which made whole swathes of swamp code irrelevant. D) allowed us to establish a sane Ci/CD Pipeline more easily which we needed to reject bad stuff. F) we ship this product every few months, so not being on lts is not really a problem.
smcl 3y ago
"It compiles so I don't need tests" is IMO more likely to be seen in relation to Haskell or Rust. Now with C# (and other popular languages) you may encounter big applications that don't have any kind of automated tests, but I don't think people are proudly declaring that compile=OK among this crowd.
- HdS84 3y ago
  I did not encounter this before also. But this crowd believed it obviously. The chief perpetrators already left when I got there, so I could not ask directly. Zero tests, zero documentation and a coding style like somebody tried to write pure C in c#.
  - smcl 3y ago
    Oh dear, that sounds quite painful!
    - HdS84 3y ago
      I like fire Fighting jobs, you always see some new insanity.
      - smcl 3y ago
        I actually get what you mean. There's something kinda rewarding about reducing chaos in a tangled system like that. At a certain point (as long as you're careful) you kind of can't go wrong, every little improvement incrementally makes the world a little bit better and the application a bit easier and more predictable to work with.

by HdS84 3y ago

Shrezzing 3y ago

> First thing I did was to get it from .net 4.8 to .net 7 This might not have been a great idea, I'm fairly surprised nobody stopped you before you went through with it. 4.8 is the "final" version of .NET Framework. It's pretty much the longest "Long Term Support" offer Microsoft will ever give for a platform, realistically they'll be supporting it into 2030 and beyond. I'd not start any new projects in it, but upgrading away from it probably wouldn't be the first thing I'd do on a new project. From .NET5, the framework moved to fundamentally different approach. It's effectively a different framework with the same NET branding on it. Most organisations who decided to move from 4.X to 6.X went through a near total rewrite because the paradigm shift is so massive, lots of organisations decided to stick with the pre-5 versions. The architecture and technology choices probably make a lot more sense in the pre-5 version of .NET, and it's unsurprising that your colleagues are frustrated with this decision, irrespective of the quality of their code. On top of the move between .NET paradigms, you've moved away from a long-term-support version. NET7 is an 18month short-term-support interim release between two Long Term Support 36month versions .NET6 and .NET8. By moving to 7, you've trapped the company into an early & rapid upgrade path to .NET8 as soon as it comes out in Nov 2023, rather than giving the full 12 month buffer you'd have got if you moved to .NET6, which is in Long Term Support until Nov 2024. You moved the application off of a rock-solid framework with near infinite long-term-support, onto a framework that'll be deprecated before in four months, and out of support entirely in ten. If I were you, I'd probably not be bringing this decision up in any performance reviews or interviews at new companies.

HdS84 3y ago
I honestly do not get what's your problem. We moved from 4.8 to 7 because a) the better compiler warnings helped to reduce the amount of shit people where able to check-in AND highlight problems in the existing codebase (beyond "well, it looks like written by the lowest bidder offshore guy drunken on Friday night") and provide management with metrics they could understand (two warnings per LOC is part of your problem). B) it deepened our hiring pool, because it's easier to find people willing to work with current technologies than legacy. C) it allowed us to pull in various modern libraries (BLe especially) which made whole swathes of swamp code irrelevant. D) allowed us to establish a sane Ci/CD Pipeline more easily which we needed to reject bad stuff. F) we ship this product every few months, so not being on lts is not really a problem.

smcl 3y ago

"It compiles so I don't need tests" is IMO more likely to be seen in relation to Haskell or Rust. Now with C# (and other popular languages) you may encounter big applications that don't have any kind of automated tests, but I don't think people are proudly declaring that compile=OK among this crowd.

HdS84 3y ago
I did not encounter this before also. But this crowd believed it obviously. The chief perpetrators already left when I got there, so I could not ask directly. Zero tests, zero documentation and a coding style like somebody tried to write pure C in c#.
- smcl 3y ago
  Oh dear, that sounds quite painful!
  - HdS84 3y ago
    I like fire Fighting jobs, you always see some new insanity.
    - smcl 3y ago
      I actually get what you mean. There's something kinda rewarding about reducing chaos in a tangled system like that. At a certain point (as long as you're careful) you kind of can't go wrong, every little improvement incrementally makes the world a little bit better and the application a bit easier and more predictable to work with.