Best Simple System for Now (2025)

There's no way to formulate this as a set of rules or best practices, each decision has to be made in a universe of context, but I appreciated this discussion.

Something I like to do is funnel the desire to build for something I don't need right now into TODOs and even FIXMEs. Sometimes they just get deleted, but other times I'll come across an old TODO during refactoring and be able to pay down a bit of accumulated technical debt.

Maybe it's different in other languages, but if I ever see hand-rolled serialization in a C# project I'm putting replacing it at the top of my to-do list. There is pretty much no reason to do that ever, serialization is a solved problem. It's flat out stupid to spend extra time hand-rolling a solution that most likely ends up buggy and requires even more work in the future etc. I also often see people waste hours or days writing custom serialization logic for a serialization library, when they could have just written a new class in the shape of the data and been done in 5 minutes.

I did work on such a project once. There was a CMS web app which needed to sync data from a third party api to rebuild some pages every night. To do this they had a client library that pulled the data twice daily and stored it in a db, then the CMS app pulled the data through the client library. The API used XML and significant parts of this library were a hand-rolled xml serializer. It worked so I didn't touch it, then it stopped working. Spent days trying to fix it but the more I studied it the more I realized it was entirely pointless. Spent about 1 day replacing the whole thing with a simple little function that just calls the api, deserializes the data using a library and builds the pages. Remove the pointless DB, remove the giant legacy quagmire integration library, this project probably took months to write and I replaced it in a day, making it orders of magnitude smaller and faster.

In the end my solution wasn't used because of office politics, apparently they'd paid a significant amount of money to use this pile of trash and replacing it that easily would make someone look bad or something. So I ended up fixing the pile of crap in the end, even though I had a replacement ready to go.

> "that meets the needs of the product"

A product itself has no needs. Users do. Governments have a kind of "need" in the form of legislation. Managing those two kinds of needs is hard enough.

This article describes one of the classic polarities in our industry, the tension between the short term and long term. There are many others, such as the tension between autonomy and alignment in organisations with lots of teams. The article did not mention polarity management, but it would help it if it did IMHO. The essence of polarity management is that the problems described can never be solved once and for all, because it's not a problem that you can fix, like you can fix, say, the damage to your car after an accident. The short term and long term tension will be ever present, and the key to managing them is to acknowledge that both have positive attributes, but both, when taken too far, have negative ones. The best advice in these kinds of situations is to work out in which direction you may have leaned too far, and lean back the other way. The key is not to dogmatically lean back too far the other way because you've treated it as a problem that can be "fixed". It can only ever be managed, and each fix creates the next imbalance.

[flagged]