6 ms·

Same here. I'm sitting here debugging some 15 year old c# at the moment in the middle of a mega shit show. I got paid. That's all the good stuff I can say abou

by hughrr 5y ago

Same here. I'm sitting here debugging some 15 year old c# at the moment in the middle of a mega shit show. I got paid. That's all the good stuff I can say about it.

tonyjstark 5y ago
I never came across code older than 2-3 years that’s not a complete clusterfuck. So looking at it from this side, the fact that it still runs is more of a sign of quality, what do you think?
- hughrr 5y ago
  Depends how much legacy .Net classic stuff you have that is in no way portable to .Net core.
  - NicoJuicy 5y ago
    https://dotnet.microsoft.com/en-us/platform/upgrade-assistant https://dotnet.microsoft.com/en-us/platform/upgrade-assistan...
    - hughrr 5y ago
      Our software broke that.
      - NicoJuicy 5y ago
        Where's the issue? https://github.com/dotnet/upgrade-assistant/issues https://github.com/dotnet/upgrade-assistant/issues Additionally: https://docs.microsoft.com/en-us/dotnet/architecture/porting-existing-aspnet-apps/?WT.mc_id=dotnet-35129-website https://docs.microsoft.com/en-us/dotnet/architecture/porting...
        hughrr 5y ago
        We don’t communicate via GitHub any more. See my other comments. Also the assistant doesn’t help with the numerous third party components which were never ported to core, the entire MVC stack internal changes or the changes that took place in NHibernate. So even if it did work it’d break everything in the process.
        NicoJuicy 5y ago
        I see a lot of complaints from you. But I should mention that nhibernate is not even in the dotnet foundation and not supported for .net core ( I visited their site and it mentions dotnet framework). I see this though: https://enterprisecraftsmanship.com/posts/nhibernate-now-supports-net-core-2-0/ https://enterprisecraftsmanship.com/posts/nhibernate-now-sup... So the issue is mostly nhibernate?
- fifticon 5y ago
  I have my own theory on this. Green-field projects are usually whipped up and rolled out by the experienced devs in the shop. Once the boat is in the water and floating, the senior devs are posted off to next new-dev initiative, and the following maintenance/deployment work is assigned to less and less senior devs, and/or student programmers. Within 2-3 years, those inexperienced devs have mangled the original design into unrecognisability, and the application accumulates instabilities from their bolted-on "fixes". A different perspective is that the original creators are never allowed back to fix their design mistakes. I don't know if it's universal, but I have sure seen it in a lot of places, and I have myself been in most of those roles hinted at.
  - SketchySeaBeast 5y ago
    Disclaimer - my job is literally to take on the long term maintenance of those green field projects. I wouldn't necessarily blame it on a lack of seniority or inexperience, it's a matter of not knowing the initial style, decisions, and limitations, as well as the vagaries of time. I find myself creating duplicate functions not because I wouldn't reuse the ones that exist, but because the original one was hidden away in a different place than I'd ever think to look for them. My approach is different and drifts even further over the years, I can't help it, so that the project starts to look stranger and stranger comparing the old code to the new. The original designers would find their style drifting too if they had to take care of a system for that long. They are just lucky enough that their style drift has project cut-offs, so each slice seems more cohesive. I also don't know if this is a current maxim or not, but there should be a software principle that matches Peter's - every successful system will grow until it reaches a point where it's no longer successful. More and more requirements get added on, and unlike initial requirements where you could justify keeping scope tight due to staying lean, a system needs to grow beyond it's current limitations or it dies.
  - JohnBooty 5y ago
    This matches pretty closely with my experience. An additional side effect is that management fails to understand what/why is going on and overvalues the skills of the "experienced devs" and undervalues the skills of the maintenance devs because they don't understand the order-of-magnitude speed advantage enjoyed by devs when writing greenfield code. "Experienced Developer A wrote the whole damn system in three months! Now Maintenance Developer B wants three months just to add a few buttons?!?" I've been both the experienced person and the junior maintenance person.
smackeyacky 5y ago
I had to debug some of my own 15 year old C# the other day, quite a reminder of how far .NET has come. Back then I rolled my own ORM and it was fun but not a patch on EFCore. One dark place some .NET devs got caught in the early days was some of the 3rd party ORMs. Nightmare of weird code, proprietary mapping tools and headaches. I am still not sold on linq2sql either. Debugging that is never fun.
- hughrr 5y ago
  Yeah those ORMs were horrible. We used NHibernate what with being sold down the river by Udi Dahan on domain modelling etc. That was a huge mistake too. Dapper is the only ORM that hasn't screwed us in some way.
- jermaustin1 5y ago
  Early on I liked Linq2SQL, and I think I still do, but it might be just looking back with rose colored glasses. When I thought I needed better control and performance I wrote my first ORM. Which wasn't really all that ORM-y. It would use reflection to map to an object, but queries definitely weren't linq-able or using IQueryable and walking the predicates to dynamically generate queries. It was more like dataBase.TableName.First("id=@id", new {id = 1}); Which would generate "select * from TableName where id=@id" nothing earth shattering. Joins were done through dataBase.Join(new [] {"table1", "table2" }, new [] {"on table1.id=table2.table1_id"}, "table1.id=@id", new {id=1}); It was ugly and I eventually just replaced it with straight ADO.net. I tried various other ORMs over the years, I eventually just settled on EF since it was not bad, and generates almost sane SQL most of the time.
  - thrower123 5y ago
    I still like Linq2Sql better than EF. It always made more sense to me to have a sanely-designed database first and then generate the mapping code from it, rather than the code-first style that seems to be popular with EF. You can do the database-first mode with entity framework, but it is less the happy path that the tooling and documentation tries to nudge you into.
bayesian_horse 5y ago
The question is not if you get paid or not but rather if you wouldn't get paid more doing something arguably more productive..
- hughrr 5y ago
  I've stopped caring but if I had to I could be paid a lot more to do something more productive. But sometimes it's nice to sit there and watch visual studio crash 30 times a day or lagging out when I hit a key because it makes me angry enough to go for a walk which I really enjoy :)
valdiorn 5y ago
"15 year old" <--- this is your problem "c#" <--- this is not Imagine what a 15 year old C++, Java, Javascript or Python project would look like. Not much different, I'm thinking...
- hackerfromthefu 5y ago
  Good luck with a 15 month old javascript system. You can possibly work with and update a C# program because of the incredible longevity/backward compatibility of the core libraries, and reasonable commitment to this in the culture of the ecosystem. But in Javascript land this can easily or even typically hit a point where the errors from package churn are so much that economically the juice is not worth the squeeze, in a literal order of magnitude less than the typical C# system.
  - taylodl 5y ago
    My company has multiple applications written in jQuery and Bootstrap that are now 10+ years old and going strong. We've been using Node.js on the backend for a little over 3 years now and those apps aren't going anywhere for quite some time. I think the notion of the continually shifting Javascript landscape has been overplayed. To wit, C++ has been changing more frequently than Javascript has!
- icedchai 5y ago
  Yep. Almost all old code bases are like this. Complexity inevitably grows over time, and old code lingers. People leave, and knowledge often fails to transfer. This is why developers prefer to work on new things: it's more fun to make the mess than to clean it up. Plus nobody wants to pay only for "maintenance"... you have to work it into other projects, which is often easier said than done.
- Weebs 5y ago
  What these all have in common though, is encouraging shared mutable references, they don't do a lot to make effects in a system explicit, don't encourage a clear organization of code, and many fundamental concepts (functions as values) were missing early on or still are (discriminated unions) I agree that pretty much any 15 year old code base is going to get rough, but I think these languages have some clear footguns that aren't doing them favors either. I work on a codebase that isn't more than a few years old, and there's complexity issues from simple things like the language lacking good semantics for transforming data immutably, and that complexity spirals I can attest that writing messy processes in languages that do address these concerns is absolutely possible, I've done so myself, but the mess is contained to a particular area and it's not as hard to follow which pieces of a system feed into another. Things as simple as making immutability the default and mutation explicit like Rust, and requiring modules be organized into a hierarchy like F# are huge wins. As much as I've gotten annoyed with F#'s project files hierarchy requirement because it requires some extra work/considerations for codependent types and codegen, it's amazing how much easier it is to jump into a new codebase where you can clearly see to understand behavior you start with the bottom of the file list, and to understand core logic/patterns you go to the top of the file list

by hughrr 5y ago

Same here. I'm sitting here debugging some 15 year old c# at the moment in the middle of a mega shit show. I got paid. That's all the good stuff I can say about it.

tonyjstark 5y ago

I never came across code older than 2-3 years that’s not a complete clusterfuck. So looking at it from this side, the fact that it still runs is more of a sign of quality, what do you think?

hughrr 5y ago
Depends how much legacy .Net classic stuff you have that is in no way portable to .Net core.
- NicoJuicy 5y ago
  https://dotnet.microsoft.com/en-us/platform/upgrade-assistant https://dotnet.microsoft.com/en-us/platform/upgrade-assistan...
  - hughrr 5y ago
    Our software broke that.
    - NicoJuicy 5y ago
      Where's the issue? https://github.com/dotnet/upgrade-assistant/issues https://github.com/dotnet/upgrade-assistant/issues Additionally: https://docs.microsoft.com/en-us/dotnet/architecture/porting-existing-aspnet-apps/?WT.mc_id=dotnet-35129-website https://docs.microsoft.com/en-us/dotnet/architecture/porting...
      - hughrr 5y ago
        We don’t communicate via GitHub any more. See my other comments. Also the assistant doesn’t help with the numerous third party components which were never ported to core, the entire MVC stack internal changes or the changes that took place in NHibernate. So even if it did work it’d break everything in the process.
        NicoJuicy 5y ago
        I see a lot of complaints from you. But I should mention that nhibernate is not even in the dotnet foundation and not supported for .net core ( I visited their site and it mentions dotnet framework). I see this though: https://enterprisecraftsmanship.com/posts/nhibernate-now-supports-net-core-2-0/ https://enterprisecraftsmanship.com/posts/nhibernate-now-sup... So the issue is mostly nhibernate?
fifticon 5y ago
I have my own theory on this. Green-field projects are usually whipped up and rolled out by the experienced devs in the shop. Once the boat is in the water and floating, the senior devs are posted off to next new-dev initiative, and the following maintenance/deployment work is assigned to less and less senior devs, and/or student programmers. Within 2-3 years, those inexperienced devs have mangled the original design into unrecognisability, and the application accumulates instabilities from their bolted-on "fixes". A different perspective is that the original creators are never allowed back to fix their design mistakes. I don't know if it's universal, but I have sure seen it in a lot of places, and I have myself been in most of those roles hinted at.
- SketchySeaBeast 5y ago
  Disclaimer - my job is literally to take on the long term maintenance of those green field projects. I wouldn't necessarily blame it on a lack of seniority or inexperience, it's a matter of not knowing the initial style, decisions, and limitations, as well as the vagaries of time. I find myself creating duplicate functions not because I wouldn't reuse the ones that exist, but because the original one was hidden away in a different place than I'd ever think to look for them. My approach is different and drifts even further over the years, I can't help it, so that the project starts to look stranger and stranger comparing the old code to the new. The original designers would find their style drifting too if they had to take care of a system for that long. They are just lucky enough that their style drift has project cut-offs, so each slice seems more cohesive. I also don't know if this is a current maxim or not, but there should be a software principle that matches Peter's - every successful system will grow until it reaches a point where it's no longer successful. More and more requirements get added on, and unlike initial requirements where you could justify keeping scope tight due to staying lean, a system needs to grow beyond it's current limitations or it dies.
- JohnBooty 5y ago
  This matches pretty closely with my experience. An additional side effect is that management fails to understand what/why is going on and overvalues the skills of the "experienced devs" and undervalues the skills of the maintenance devs because they don't understand the order-of-magnitude speed advantage enjoyed by devs when writing greenfield code. "Experienced Developer A wrote the whole damn system in three months! Now Maintenance Developer B wants three months just to add a few buttons?!?" I've been both the experienced person and the junior maintenance person.

smackeyacky 5y ago

I had to debug some of my own 15 year old C# the other day, quite a reminder of how far .NET has come. Back then I rolled my own ORM and it was fun but not a patch on EFCore. One dark place some .NET devs got caught in the early days was some of the 3rd party ORMs. Nightmare of weird code, proprietary mapping tools and headaches. I am still not sold on linq2sql either. Debugging that is never fun.

hughrr 5y ago
Yeah those ORMs were horrible. We used NHibernate what with being sold down the river by Udi Dahan on domain modelling etc. That was a huge mistake too. Dapper is the only ORM that hasn't screwed us in some way.
jermaustin1 5y ago
Early on I liked Linq2SQL, and I think I still do, but it might be just looking back with rose colored glasses. When I thought I needed better control and performance I wrote my first ORM. Which wasn't really all that ORM-y. It would use reflection to map to an object, but queries definitely weren't linq-able or using IQueryable and walking the predicates to dynamically generate queries. It was more like dataBase.TableName.First("id=@id", new {id = 1}); Which would generate "select * from TableName where id=@id" nothing earth shattering. Joins were done through dataBase.Join(new [] {"table1", "table2" }, new [] {"on table1.id=table2.table1_id"}, "table1.id=@id", new {id=1}); It was ugly and I eventually just replaced it with straight ADO.net. I tried various other ORMs over the years, I eventually just settled on EF since it was not bad, and generates almost sane SQL most of the time.
- thrower123 5y ago
  I still like Linq2Sql better than EF. It always made more sense to me to have a sanely-designed database first and then generate the mapping code from it, rather than the code-first style that seems to be popular with EF. You can do the database-first mode with entity framework, but it is less the happy path that the tooling and documentation tries to nudge you into.

bayesian_horse 5y ago

The question is not if you get paid or not but rather if you wouldn't get paid more doing something arguably more productive..

hughrr 5y ago
I've stopped caring but if I had to I could be paid a lot more to do something more productive. But sometimes it's nice to sit there and watch visual studio crash 30 times a day or lagging out when I hit a key because it makes me angry enough to go for a walk which I really enjoy :)

valdiorn 5y ago

"15 year old" <--- this is your problem "c#" <--- this is not Imagine what a 15 year old C++, Java, Javascript or Python project would look like. Not much different, I'm thinking...

hackerfromthefu 5y ago
Good luck with a 15 month old javascript system. You can possibly work with and update a C# program because of the incredible longevity/backward compatibility of the core libraries, and reasonable commitment to this in the culture of the ecosystem. But in Javascript land this can easily or even typically hit a point where the errors from package churn are so much that economically the juice is not worth the squeeze, in a literal order of magnitude less than the typical C# system.
- taylodl 5y ago
  My company has multiple applications written in jQuery and Bootstrap that are now 10+ years old and going strong. We've been using Node.js on the backend for a little over 3 years now and those apps aren't going anywhere for quite some time. I think the notion of the continually shifting Javascript landscape has been overplayed. To wit, C++ has been changing more frequently than Javascript has!
icedchai 5y ago
Yep. Almost all old code bases are like this. Complexity inevitably grows over time, and old code lingers. People leave, and knowledge often fails to transfer. This is why developers prefer to work on new things: it's more fun to make the mess than to clean it up. Plus nobody wants to pay only for "maintenance"... you have to work it into other projects, which is often easier said than done.
Weebs 5y ago
What these all have in common though, is encouraging shared mutable references, they don't do a lot to make effects in a system explicit, don't encourage a clear organization of code, and many fundamental concepts (functions as values) were missing early on or still are (discriminated unions) I agree that pretty much any 15 year old code base is going to get rough, but I think these languages have some clear footguns that aren't doing them favors either. I work on a codebase that isn't more than a few years old, and there's complexity issues from simple things like the language lacking good semantics for transforming data immutably, and that complexity spirals I can attest that writing messy processes in languages that do address these concerns is absolutely possible, I've done so myself, but the mess is contained to a particular area and it's not as hard to follow which pieces of a system feed into another. Things as simple as making immutability the default and mutation explicit like Rust, and requiring modules be organized into a hierarchy like F# are huge wins. As much as I've gotten annoyed with F#'s project files hierarchy requirement because it requires some extra work/considerations for codependent types and codegen, it's amazing how much easier it is to jump into a new codebase where you can clearly see to understand behavior you start with the bottom of the file list, and to understand core logic/patterns you go to the top of the file list