5 ms·

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

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.

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.