It makes me really sad to read things like this. .NET/C# gives you the tools to write elegant, performant code in any domain, and really rewards high level of expertise, with stuff like advanced parallelism support, and optimizing things like memory layout with structs, really great native interop story, or the ability to write Source Generators/Analyzers, so you can develop AST-parsing compiler plugins to do stuff like automated code generation/analysis.

Imo it has a way higher skill ceiling, than something like, say NodeJS, which is supposedly part of the cool kids club.

I have literally had conversations with hardcore devs that had the 'enterprise offshore-bait' perception of the language and were surprised when I showed them all the awesome stuff you can do with it.

C# is a well-regarded choice for the application layer in the engineering software world. You'd need a good reason not to choose it.

It's very much a problem with the orgs and the typical culture at these types of orgs. It's not a problem with the tech.

Someone mentioned Unity. I'm really curious as to what typical C# Unity codebase looks like since I imagine a Unity game dev shop would culturally be very, very, different from a big enterprise .NET shop.

I would argue the 'standard' Unity game dev shop are made of experienced burned out developpers from 'standard tech' big shops managing enthousiastics but 'incompetents' (I quote the word i'm not sure it's the good one, it's not they are bad as persons but they lack experience and game development school have an abyssal level of formation in programming) interns, wich is not different than a lot a place I worked before going to game development (and sometime as the enthousiastic but unproductive intern myself of course) ^^

My impression from hanging out on Unity forums / reading tutorials/ code snippets, is that the usual Unity developer is not a very experienced coder, often getting into programming to make games, or lacks a traditional SW development background and wants to just make cool stuff, without a regard for typical SWE concerns. Not that any of this is a bad thing, mind you.

Not sure about how representative is this of the typical professional Unity dev.

That's because every commercially successful project eventually turns into an absolute mess.

The others go bankrupt before it happens.

Exactly, survivorship bias. I find C# to be a beautiful and elegant language. And if you wanna see what .net is capable of, you have to look at core projects, asp.net, entity framework, ml.net, ... Not what random businesses and their poor specs built in a haste project look like.

The unnecessary over-engineering is still a factor in large corporations.

The unnecessary not-taking-care of technology (so the anti-over-engineering) is also a factor in large corporations ;).

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.

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?

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.

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.

It's also that requirements often change in ways the original design hadn't foreseen. And usually there's no time for a decent redesign, so things get hacked together and slowly degrade hack by hack

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.

Exactly! As a maintenance dev, you tend not to get much praise, you need to continuously explain why things take so long. I'm currently adapting some code that is, in the eyes of management, adding an extra little wire, which should not be more than a day of work. In effect it will be more than 4 days plus some overtime...

Yeah. I've been in the industry for 20+ years and I have not figured out a way to "shine" when tasked with maintenance work, other than finding ways to avoid such roles entirely.

The root issue is that management never seems to be able to grasp things on a technical level. I've tried to communicate this over the years, and have been praised for my communication skills in general, but I've never managed to bridge this particular gap.

This plays some part. Another factor is the old 'it is harder to read code than it is to write it' adage.

Depends how much legacy .Net classic stuff you have that is in no way portable to .Net core.

Our software broke that.

Where's the issue? https://github.com/dotnet/upgrade-assistant/issues

Additionally: https://docs.microsoft.com/en-us/dotnet/architecture/porting...

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.

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-sup...

So the issue is mostly nhibernate?

"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...

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.

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!

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

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.

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.

I'm kind of sentimental for EF, as I think it can be a handy tool, but in my experience, ORMs of any kind are not suited to serious work, they usually assume that they own the database creation, which is fine when you are building a webshop, but obviously not, when you are interacting with a large existing database.

ORM-lites, such as Dapper, which only bind query results to objects, are an obvious exception thoug.

It’s my experience that ORM “frameworks” are a net negative for anything that needs scale or performance. They’re optimized for demos and quick setup but fall apart as soon as the system needs to scale. Straight deserialization is generally a win but the “magic” never is and fighting with it when it doesn’t work is way more pain that writing some SQL.

Every time I’ve seen a project use an ORM past the proof of concept phase, it ends up with some garbage layer to bypass or “trick” the ORM into doing something acceptable. (e.g. Complex materialized views presented as tables to the ORM so the ORM can just do straight selects without joins).

Speaking of databases: In my experience, denormalizing usually doesn't help either with performance. Hell, often normalizing it more leads to it actually being faster. (Assuming appropriate indices)

Depends on the query patterns, but certainly denormalization is not an automatic win.

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.

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.

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.

I've always been frustrated that active record ORMs have completely overtaken tools like Linq2Sql.

I don't deny the value of the active record pattern where it works, but in almost every case I've used SQL over the past 5 years, I don't want a complex abstraction layer. I just want something to make it easy and safe to talk to the database for the 90% of straight forward queries we write.

With something like that, I feel as though I'd rather write my own active record system than use the configuration based systems we see with EF

>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'm looking at you LLBLGen

Also EntitySpaces. Not sure what they were thinking. Anything that used EntitySpaces needed a complete re-write as it spawned a living hell of class definitions and mappings that locked you into a particular style of programming that was hideous.

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

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 :)

I really think this is because of the way companies act and not the fault of any technology. We work in a field where companies really believe they should try for the cheapest labor possible without thinking about the consequences. When written with thought programs with .NET or any other platform work well. When you start replacing the person who had real knowledge and experience with the recent boot camp grad, "because that was the more affordable option" that's when problems start to arise.

All Microsoft tech has an aura of mediocrity, but I guess that is part of the appeal too.

It's like keeping an old Oldsmobile running, it doesn't make sense but you get respect when cruising the hood.

But with .Net you're pushing a trolley full of cans down the road while dressed in rags.

I liked working with FxCop and StyleCop.

I liked seeing the expressions of frustration when developers that were sloppy with their coding style were no longer able to get away with code that didn't meet the coding standards.

When it was adopted it literally made some people scream in frustration, and I loved it for that.

The default ruleset of StyleCop is absolutely brutal and unforgiving with messy code.

I tend to be of the camp that if a tool can automatically detect issues, they usually aren't that important of an issue. The real messes that lose money can't be cleaned with a formatter or detected with a tool.

Some problems could be fixed by autoformatting, some others could not because they involved a decision.

For example:

- StyleCop validated variable names beyond just casing, and forced you to decide how to comply.

- StyleCop validated the number of arguments in methods, the length of a method and the length of statements.

- StyleCop would identify situations when a variable should be created for a expression.

Every large mess starts as a smaller mess, and that smaller mess is usually low quality code.

I was tasked with running an autocorrector on all our code once in 6 months. On average, out of thousands problems it detected, 1-2 came out as real hard bugs, that would never been caught by programmers or the testing team. 1-2 bugs for a day of work is not that bad.

I wonder if this is because the languages we use today like C#, Java etc evolves mostly horizontally, like standard library improvements, syntactic sugar, performance etc, instead of vertically like higher abstraction and modularity.

What I’m trying to say is that we lack abstractions to model our intent on a higher level.

I think that is why we invent things like micro services because we can’t express modularity on higher level good enough , when that type of abstraction should be built into the language itself (and irrelevant if it is on a separate network node or not).

I guess Java modules is a go at this, don’t know if successful or not.

That is how I at least feel when I’m maneuvering huge projects, a building block is missing.

companies more so than the tech, I do Java in the banking space and its the same story.

Seems like .net shops uses DDD+CQRS+ES by default. Don't ask me why.

It's not a requirement. But in general it's because it's 1 clean code path.

I don't think ES is as common as you think though. CQRS is.

What is ES? For those reading, DDD is Domain-driven Design, and CQRS is Command and Query Responsibility Segregation. But what is ES?

Event sourcing

Perfect, thanks!

Not from what I've seen, having worked across many many dozens of codebases, in various enterprises and also as a consultant.

Though yes there were definitely some influenced by Udi Dahan that use or aspired to use those.

Virtually every software company is like this as I understand.

Don’t bite the hand that feeds you :)