4 ms·

The other way around you have the "it compiles, so I don't need tests" crowd in statically-typed languages.

erik_seaberg 3y ago
This might sort of work if everything from the domain gets a disjoint type, but stringly-typed code is a lot more common and the type system doesn’t know what would make sense.
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.
cjfd 3y ago
Are there many people like that? In actuality, writing software that is some quality is so hard that one needs all help one can get. One absolutely needs type checking and is just not professional without. One absolutely needs automated tests and is just not professional without. One absolutely needs manual/exploratory testing and is just not professional without.
- wirrbel 3y ago
  In my experience this depends a lot on the organizations. If the organization's expectation is that sometimes, no tests would be ok, then quickly these people emerge who think that writing tests slows them down. If culture is that tests are necessary, then these people hide and write their tests (or actually learn that test-writing makes sense). I am in an organization currently that values testing overall, but being in a regulated industry its almost a little over-done, the result of that is, that for prototypes, tools, etc. the rules are weakened, leading to this weird situation where "of course we write tests, but this was just our prototype, that runs in production, for 3 years" seems to work in some departments...
- formerly_proven 3y ago
  Despite being unprofessional smelly amateurs, dynamically-typed scripting languages delivered and continue to deliver amazing amounts of business value. Which is really the only thing a business cares about, as professionals know.
  - MrJohz 3y ago
    I mean, you can do good work with Visual Basic and an overworked Excel spreadsheet, but it will probably be worth your while to find some alternatives. Just because something works, doesn't mean we can't improve it, and just because we can deliver value with one tool, doesn't mean that we couldn't be delivering more value with other tools.
- roflyear 3y ago
  Yes, absolutely. Or they insist on only integration tests that take hours to run and are horrible to maintain.
hdjfkxmdnrkfkn 3y ago
You always need tests... No its buts or maybes

This might sort of work if everything from the domain gets a disjoint type, but stringly-typed code is a lot more common and the type system doesn’t know what would make sense.

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.

cjfd 3y ago

Are there many people like that? In actuality, writing software that is some quality is so hard that one needs all help one can get. One absolutely needs type checking and is just not professional without. One absolutely needs automated tests and is just not professional without. One absolutely needs manual/exploratory testing and is just not professional without.

wirrbel 3y ago
In my experience this depends a lot on the organizations. If the organization's expectation is that sometimes, no tests would be ok, then quickly these people emerge who think that writing tests slows them down. If culture is that tests are necessary, then these people hide and write their tests (or actually learn that test-writing makes sense). I am in an organization currently that values testing overall, but being in a regulated industry its almost a little over-done, the result of that is, that for prototypes, tools, etc. the rules are weakened, leading to this weird situation where "of course we write tests, but this was just our prototype, that runs in production, for 3 years" seems to work in some departments...
formerly_proven 3y ago
Despite being unprofessional smelly amateurs, dynamically-typed scripting languages delivered and continue to deliver amazing amounts of business value. Which is really the only thing a business cares about, as professionals know.
- MrJohz 3y ago
  I mean, you can do good work with Visual Basic and an overworked Excel spreadsheet, but it will probably be worth your while to find some alternatives. Just because something works, doesn't mean we can't improve it, and just because we can deliver value with one tool, doesn't mean that we couldn't be delivering more value with other tools.
roflyear 3y ago
Yes, absolutely. Or they insist on only integration tests that take hours to run and are horrible to maintain.

hdjfkxmdnrkfkn 3y ago

You always need tests... No its buts or maybes