3 ms·

I always default to redundancy until I can't stand it anymore, or it has actually caused an issue. For me, the real devil is the clarity of requirements and in

I always default to redundancy until I can't stand it anymore, or it has actually caused an issue. For me, the real devil is the clarity of requirements and intended product roadmap. If the thing you are building is crystalline & eternal with 100% obvious requirements on day #1, then sure. Spend all afternoon in the architecture rabbit hole and make a likewise implementation. I've never worked on a project where you can plan this far ahead. Think about what happens when you allow 2 different developers to work on 2 distinct features that share a (vague) common concept, but then encourage them to independently implement that common concept. Some developers look at this like an inconsistent horror show. I look at it as additional options to choose from. At the end of the day, you can always come back and de-dupe these common types and re-align implementations accordingly.

ChrisMarshallNY 4y ago
This. A big part of my refactoring is distilling base classes, and protocol defaults (I was just doing exactly that, a few minutes ago, in fact). I have watched so many dependapocalyses, that I have a healthy fear. I no longer have to touch that particular stove-lid, to know that it's hot. There are a number of serious issues with dependencies. In many cases, they are great. They can give a fairly inexperienced programmer, massive power. In many other cases, they are not great. They can give a fairly inexperienced programmer, massive power. But I use them frequently, in my own work. It's called "Modular Programming," and the concept is decades old. I write almost all my modules, and include them as packages, with static linking. Each package tends to be a fairly standalone, atomic software project, with its own lifecycle.
- bob1029 4y ago
  > They can give a fairly inexperienced programmer, massive power. (x2) This is a big reason why we use one of the broadest frameworks available in modern tooling today - .NET 6+. It has so many batteries included that pulling in a 3rd party dependency is something rare enough to call a big meeting for. Additionally, that "dependency" is the same one everyone else uses - not just in our organization - so all that code could be shared with minimal friction. There are certainly downsides to this - what if Microsoft becomes even more evil? But, we can hypothesize about the end of the world while our competition uses the same trick and steals all of our lunch money...

ChrisMarshallNY 4y ago

This. A big part of my refactoring is distilling base classes, and protocol defaults (I was just doing exactly that, a few minutes ago, in fact). I have watched so many dependapocalyses, that I have a healthy fear. I no longer have to touch that particular stove-lid, to know that it's hot. There are a number of serious issues with dependencies. In many cases, they are great. They can give a fairly inexperienced programmer, massive power. In many other cases, they are not great. They can give a fairly inexperienced programmer, massive power. But I use them frequently, in my own work. It's called "Modular Programming," and the concept is decades old. I write almost all my modules, and include them as packages, with static linking. Each package tends to be a fairly standalone, atomic software project, with its own lifecycle.

bob1029 4y ago
> They can give a fairly inexperienced programmer, massive power. (x2) This is a big reason why we use one of the broadest frameworks available in modern tooling today - .NET 6+. It has so many batteries included that pulling in a 3rd party dependency is something rare enough to call a big meeting for. Additionally, that "dependency" is the same one everyone else uses - not just in our organization - so all that code could be shared with minimal friction. There are certainly downsides to this - what if Microsoft becomes even more evil? But, we can hypothesize about the end of the world while our competition uses the same trick and steals all of our lunch money...