8 ms·

Well it has kept me employee for quite some time now so that's something to celebrate. The opposite side to that it I think every commercial .Net system I've e

Well it has kept me employee for quite some time now so that's something to celebrate. The opposite side to that it I think every commercial .Net system I've ever worked with / on has been an absolute mess. Not sure if it's .Net or the companies but something there seems to attract devs to make ill performing, over abstracted, confusing, massive architecture systems that in reality could be simplified down to a bunch of data forms. As I say I shouldn't complain keeping these things running pays my bills.

mbrodersen 5y ago
Don’t bite the hand that feeds you :)
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
ahoka 5y ago
All Microsoft tech has an aura of mediocrity, but I guess that is part of the appeal too.
- speed_spread 5y ago
  It's like keeping an old Oldsmobile running, it doesn't make sense but you get respect when cruising the hood.
  - hughrr 5y ago
    But with .Net you're pushing a trolley full of cans down the road while dressed in rags.
29athrowaway 5y ago
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.
- JackMorgan 5y ago
  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.
  - EVa5I7bHFq9mnYK 5y ago
    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.
  - 29athrowaway 5y ago
    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.
marcos100 5y ago
Seems like .net shops uses DDD+CQRS+ES by default. Don't ask me why.
- hackerfromthefu 5y ago
  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.
- NicoJuicy 5y ago
  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.
  - fullstackchris 5y ago
    What is ES? For those reading, DDD is Domain-driven Design, and CQRS is Command and Query Responsibility Segregation. But what is ES?
    - mpmpmpmp 5y ago
      Event sourcing
      - fullstackchris 5y ago
        Perfect, thanks!
nikanj 5y ago
That's because every commercially successful project eventually turns into an absolute mess. The others go bankrupt before it happens.
- rafale 5y ago
  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.
- cm2187 5y ago
  The unnecessary over-engineering is still a factor in large corporations.
  - oaiey 5y ago
    The unnecessary not-taking-care of technology (so the anti-over-engineering) is also a factor in large corporations ;).
em10fan 5y ago
companies more so than the tech, I do Java in the banking space and its the same story.
kemiller2002 5y ago
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.
tored 5y ago
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.
torginus 5y ago
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.
- decafninja 5y ago
  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.
  - GaelFG 5y ago
    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) ^^
    - torginus 5y ago
      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.
throwaway6532 5y ago
Virtually every software company is like this as I understand.

mbrodersen 5y ago

Don’t bite the hand that feeds you :)

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

ahoka 5y ago

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

speed_spread 5y ago
It's like keeping an old Oldsmobile running, it doesn't make sense but you get respect when cruising the hood.
- hughrr 5y ago
  But with .Net you're pushing a trolley full of cans down the road while dressed in rags.

29athrowaway 5y ago

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.

JackMorgan 5y ago
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.
- EVa5I7bHFq9mnYK 5y ago
  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.
- 29athrowaway 5y ago
  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.

marcos100 5y ago

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

hackerfromthefu 5y ago
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.
NicoJuicy 5y ago
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.
- fullstackchris 5y ago
  What is ES? For those reading, DDD is Domain-driven Design, and CQRS is Command and Query Responsibility Segregation. But what is ES?
  - mpmpmpmp 5y ago
    Event sourcing
    - fullstackchris 5y ago
      Perfect, thanks!

nikanj 5y ago

That's because every commercially successful project eventually turns into an absolute mess. The others go bankrupt before it happens.

rafale 5y ago
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.
cm2187 5y ago
The unnecessary over-engineering is still a factor in large corporations.
- oaiey 5y ago
  The unnecessary not-taking-care of technology (so the anti-over-engineering) is also a factor in large corporations ;).

em10fan 5y ago

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

kemiller2002 5y ago

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.

tored 5y ago

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.

torginus 5y ago

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.

decafninja 5y ago
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.
- GaelFG 5y ago
  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) ^^
  - torginus 5y ago
    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.

throwaway6532 5y ago

Virtually every software company is like this as I understand.