12 ms·

Some time ago I had the misfortune to direct a C#/ASP.net web project, and that project turned out to be the first web project where the backend was singnifican

Some time ago I had the misfortune to direct a C#/ASP.net web project, and that project turned out to be the first web project where the backend was singnificantly later than the frontend. Even though the backend had 2 senior developers and the frontend only 1 junior developer doing React. Since then I am not able to take seriously the saying of .net to be "incredibly productive".

mkr-hn 5y ago
This comment could benefit from development. For example: how do you know .NET was the cause? Anecadata can be useful in aggregate, but not with such sparse details.
deleted 5y ago
[deleted]
manigandham 5y ago
What do you mean by direct? Were you doing the coding? And the backend was larger in what way? And is that a problem? And was the frontend a SPA? Was asp.net just used to make a JSON API? What were the actual issues and what would've made it more productive? That's much more useful for discussion here.
- javcasas 5y ago
  I initially directed (as organise stories, unblock people, do some devops & code review), but eventually I had to jump into the backend, because, as the most senior developer, I'm expected to jump into whatever part is having trouble. The backend had to receive events from a webhook and accumulate statistics on those events, then serve these statistics via REST API Frontend was plain old React reaching the REST API. Issues: * The database (MS SQL Server, as recommended by Microsoft) would randomly lock up for days. Bear in mind this was a 1GB of RAM (the minimum amount that Microsoft accepts as enough to run a SQL Server instance) RDS serving around 600 MB of data. * The introduction of the Repository Pattern (as recommended by the ASP.net documentation) introduced a lot of complexity (including incompleted/non-defined operations) that slowed down significantly the development. * LINQ supports interleaving DB operations with not-db operations, quickly becoming a O(n^m) footguns. If you make `row => row.x > 5` a method, LINQ will happily download all the rows and run the comparison in program instead of in the DB. Bear in mind I can't construct these footguns with django ORM, or make them typecheck with any Haskell data access framework. * The test runner UI would pretend no tests existed if the code didn't compile for any reason. Trying to debug something by running a specific failing test? If you miss a semicolon now you have to go find your test again. * The logger would log the message and the affected class in different lines. Do you want to grep for an error? You better know the obscure grep syntax for "previous line". Want to change the logging format? Good luck finding the code that adds the newline in order to find how to influence it. If you ask the IDE to find the implementation of the logging function it will show you the interface, nothing more. * You better not do some type of async stuff in LINQ, because the system is going to spawn a process for each entry, obliterating your production instance by creating thousands of processes, using a bunch of MB for each process. There were more issues, I didn't make an exhaustive list of them because, you know, I don't need to make exhaustive lists of malfunctions and bad design ideas for other programming languages.
  - hallway_monitor 5y ago
    Based on this anecdote, it sounds like the team had little or no .net experience and your seniors probably don't deserve the title.
    - javcasas 5y ago
      Curiously, I haven't had these problems in Python/cherrypy/django/flask, Haskell/snap/yesod, NodeJS/express/nextjs, so, maybe it's something beyond lack of .net experience.
      - tomrod 5y ago
        Your experience mirrors mine, both early (circa 2005) and more recently. Footguns are common. I am not sure where the .NET community coalesces (python and similar tend to hit up IRC).
        topkai22 5y ago
        The ability to find and get answers on stack overflow is pretty impressive, although that might not be the “community” your looking for. I’ve had decent direct engagements with them framework dev tends on GitHub before as well.
        tomrod 5y ago
        To add on to community -- it's more than that as well, it's the zeitgeist. In the scientific computing world, if something has hit NumFocus' portfolio then it's active, maintained, accessible, and (IMO) can consider adding into a tech stack. Similar for Apache for general FLOSS projects. I don't understand the dotnet's extension ecosystem -- how to find quality sourcing, etc. Going from an established project into dotnet SDK makes sense. But searching GitHub for useful dotnet frameworks -- stars are probably misleading here?
      - koide 5y ago
        There's been lots of bad decisions along the way for .net, but In its current state (.net Core 6) I can't really see any of your problems happening. Although what strikes me most is your first point. Running SQL server on 1gb and complaining that it didn't work well isn't really wise. Maybe this happened on the early years of .net Core or even on FF?
osigurdson 5y ago
Usually in these situations I switch the junior developer to the back end which often increases velocity by 20%. Then let one of the senior devs take a brief vacation since they can be having issues at home. Usually by the time they are back, everything flows smoothly, velocity doubles and clients are pleased. I believe this approach can be tweaked to work even when the back end is done in .NET.
johncoltrane 5y ago
Funny how differently the grandparent's anecdotic but positive comment and this anecdotic but negative comment are treated.
- thawaya3113 5y ago
  For one thing, the negative comment appears to be claiming that the backend being more complex than the front end is a very strong indicator that the backend tooling was worse, and that in a web project, everything else equal, the front end should always take longer than the back end. The entire premise is dubious, and even if the premise is correct, blaming it on the framework without any other evidence seems like a stretch.
  - jwdunne 5y ago
    Aye, I noticed this too and I’ve never written a line of production C# in my life. On the projects I’ve worked on recently, the backend often ended up far more complex than the frontend, taking up more time to build and maintain. This is natural. The backends were responsible for interfacing with other systems, like databases, 3rd party APIs and message queues, for example. The frontends, on the other hand, generally interfaced with only one system: the backend. Am I arguing that the frontend is never more complex and time consuming than the backend? Not at all. But I don’t think you can blame the backend stack and tooling for the resultant imbalance of complexity between the two systems.
- manigandham 5y ago
  Because the issues described downstream are bordering on ridiculous and betray lack of knowledge of how to use the ecosystem rather than a problem with the stack itself.
DeathArrow 5y ago
I commissioned a house. The guy who did the paint job finished faster than the two guys who laid the bricks and did everything else. It clearly means that the bricks are of poor quality, I will never buy the same bricks again.
- javcasas 5y ago
  I commisioned another house. I have been building houses for the last 5 years. During these years I have seen that the bricklayers tend to take around 20% less time than the painters, furniture-installers and decorators. Somehow, in this project, with bricks provided by BigCorp the bricklayers are significantly late, and are delaying the whole project. It doesn't clearly mean anything other than I'm not willing to risk another late house by using again the bricks from BigCorp

mkr-hn 5y ago

This comment could benefit from development. For example: how do you know .NET was the cause? Anecadata can be useful in aggregate, but not with such sparse details.

deleted 5y ago

[deleted]

manigandham 5y ago

What do you mean by direct? Were you doing the coding? And the backend was larger in what way? And is that a problem? And was the frontend a SPA? Was asp.net just used to make a JSON API? What were the actual issues and what would've made it more productive? That's much more useful for discussion here.

javcasas 5y ago
I initially directed (as organise stories, unblock people, do some devops & code review), but eventually I had to jump into the backend, because, as the most senior developer, I'm expected to jump into whatever part is having trouble. The backend had to receive events from a webhook and accumulate statistics on those events, then serve these statistics via REST API Frontend was plain old React reaching the REST API. Issues: * The database (MS SQL Server, as recommended by Microsoft) would randomly lock up for days. Bear in mind this was a 1GB of RAM (the minimum amount that Microsoft accepts as enough to run a SQL Server instance) RDS serving around 600 MB of data. * The introduction of the Repository Pattern (as recommended by the ASP.net documentation) introduced a lot of complexity (including incompleted/non-defined operations) that slowed down significantly the development. * LINQ supports interleaving DB operations with not-db operations, quickly becoming a O(n^m) footguns. If you make `row => row.x > 5` a method, LINQ will happily download all the rows and run the comparison in program instead of in the DB. Bear in mind I can't construct these footguns with django ORM, or make them typecheck with any Haskell data access framework. * The test runner UI would pretend no tests existed if the code didn't compile for any reason. Trying to debug something by running a specific failing test? If you miss a semicolon now you have to go find your test again. * The logger would log the message and the affected class in different lines. Do you want to grep for an error? You better know the obscure grep syntax for "previous line". Want to change the logging format? Good luck finding the code that adds the newline in order to find how to influence it. If you ask the IDE to find the implementation of the logging function it will show you the interface, nothing more. * You better not do some type of async stuff in LINQ, because the system is going to spawn a process for each entry, obliterating your production instance by creating thousands of processes, using a bunch of MB for each process. There were more issues, I didn't make an exhaustive list of them because, you know, I don't need to make exhaustive lists of malfunctions and bad design ideas for other programming languages.
- hallway_monitor 5y ago
  Based on this anecdote, it sounds like the team had little or no .net experience and your seniors probably don't deserve the title.
  - javcasas 5y ago
    Curiously, I haven't had these problems in Python/cherrypy/django/flask, Haskell/snap/yesod, NodeJS/express/nextjs, so, maybe it's something beyond lack of .net experience.
    - tomrod 5y ago
      Your experience mirrors mine, both early (circa 2005) and more recently. Footguns are common. I am not sure where the .NET community coalesces (python and similar tend to hit up IRC).
      - topkai22 5y ago
        The ability to find and get answers on stack overflow is pretty impressive, although that might not be the “community” your looking for. I’ve had decent direct engagements with them framework dev tends on GitHub before as well.
        tomrod 5y ago
        To add on to community -- it's more than that as well, it's the zeitgeist. In the scientific computing world, if something has hit NumFocus' portfolio then it's active, maintained, accessible, and (IMO) can consider adding into a tech stack. Similar for Apache for general FLOSS projects. I don't understand the dotnet's extension ecosystem -- how to find quality sourcing, etc. Going from an established project into dotnet SDK makes sense. But searching GitHub for useful dotnet frameworks -- stars are probably misleading here?
    - koide 5y ago
      There's been lots of bad decisions along the way for .net, but In its current state (.net Core 6) I can't really see any of your problems happening. Although what strikes me most is your first point. Running SQL server on 1gb and complaining that it didn't work well isn't really wise. Maybe this happened on the early years of .net Core or even on FF?

osigurdson 5y ago

Usually in these situations I switch the junior developer to the back end which often increases velocity by 20%. Then let one of the senior devs take a brief vacation since they can be having issues at home. Usually by the time they are back, everything flows smoothly, velocity doubles and clients are pleased. I believe this approach can be tweaked to work even when the back end is done in .NET.

johncoltrane 5y ago

Funny how differently the grandparent's anecdotic but positive comment and this anecdotic but negative comment are treated.

thawaya3113 5y ago
For one thing, the negative comment appears to be claiming that the backend being more complex than the front end is a very strong indicator that the backend tooling was worse, and that in a web project, everything else equal, the front end should always take longer than the back end. The entire premise is dubious, and even if the premise is correct, blaming it on the framework without any other evidence seems like a stretch.
- jwdunne 5y ago
  Aye, I noticed this too and I’ve never written a line of production C# in my life. On the projects I’ve worked on recently, the backend often ended up far more complex than the frontend, taking up more time to build and maintain. This is natural. The backends were responsible for interfacing with other systems, like databases, 3rd party APIs and message queues, for example. The frontends, on the other hand, generally interfaced with only one system: the backend. Am I arguing that the frontend is never more complex and time consuming than the backend? Not at all. But I don’t think you can blame the backend stack and tooling for the resultant imbalance of complexity between the two systems.
manigandham 5y ago
Because the issues described downstream are bordering on ridiculous and betray lack of knowledge of how to use the ecosystem rather than a problem with the stack itself.

DeathArrow 5y ago

I commissioned a house. The guy who did the paint job finished faster than the two guys who laid the bricks and did everything else. It clearly means that the bricks are of poor quality, I will never buy the same bricks again.

javcasas 5y ago
I commisioned another house. I have been building houses for the last 5 years. During these years I have seen that the bricklayers tend to take around 20% less time than the painters, furniture-installers and decorators. Somehow, in this project, with bricks provided by BigCorp the bricklayers are significantly late, and are delaying the whole project. It doesn't clearly mean anything other than I'm not willing to risk another late house by using again the bricks from BigCorp