• (nodebb)

    Well, is great to come home back to Europe and literally end up with an article on TDWTF that plagues the client I "visited" over the last few days. In the end it's pretty simple: Either there is a proper contract organizing data or there isn't. When you have an contract in place, then it's hard to get the data in. When there is no contract in place, then it's hard to get the data out. There is no easy way, in the end it's similar to entropy, data is always data but it varies in it's usefulness and that in the end dictates how expensive processing will be.

  • (nodebb)

    Ref

    When you have an contract in place, then it's hard to get the data in. When there is no contract in place, then it's hard to get the data out.

    Very well said. There's a corollary that's triggering for me. Data gathering & input is expensive, laborious, and invisible to management. Data reporting is totally visible to management. I can't count the number of times I was asked to concoct a solution to reporting data that wasn't gathered and wouldn't / couldn't be gathered. Only to be met by blank stares and "Why not?"

  • giammin (unregistered)

    just to add a wtf to the wtf: JsonPropertyName is useless also because it specifies the property name that is present in the JSON when serializing and deserializing and you could use a global option to camelCase the properties

  • (nodebb)

    There's a tiny mistakes in the article:

    The field InvitedTradersV2 (...)

    InvitedTradersV2 is an auto-property (https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties) , not a field.

    But that means the consuming application doesn't know which key it should check.

    Overloading DTOs with specific versions is not uncommon and not really bad practice either. It is often done to support zero-down-time migration support. How it will be handled depends on how it was implemented: It could be as simple as that V2 has priority when not null up to V1 being actively set to null to avoid confusion and additional heap allocations. Since that is even an implementation detail, it doesn't even have to be part of a story but should be defined in the contract either with XML comments or written documentation.

    (...) instead uses Newtonsoft.JSON, a popular third-party library for solving the problem (...)

    System.Text.Json has pretty much obsoleted Newtonsoft by now. It has better performance, is already used by most standard components and beside a few edge cases which are often considered borderline bad-practice anyway, there is little reason to actually use it in 2025. So I guess there was some attempt to migrate away from Newtonsoft but some line manager killed the effort half-way through. Nothing really uncommon sadly.

    So yeah, it's not as bad as it seems. This is more a result of put data in and later deal with the garbage than can't be as easily adjust as for example a rename of a column in a relational DB. You can either deal with DB migration or you have to deal with never ending legacy support like this; personally I prefer a fix-it-once design.

  • Drak (unregistered) in reply to MaxiTB

    When we migrated away from NewtonSoft we had a few oddball errors appearing in the product because system.text.json has some different assumptions / makes different choices in some places. Even a full regression test did not find all the issues, so I can sort of understand not wanting to migrate away from it if you don't have a production cycle that can quickly fix issues that might crop up unexpectedly.

  • Joahi93 (github)

    Interesting perspective on the “Pawn in the Game of Life” idea — sometimes it really does feel like small moves matter more than big ones.

Leave a comment on “Pawn Pawn in in Game Game of of Life Life”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article