"Not too much" is interesting. If I understand you correctly, you can write "too much software". I can think of at least three ways - bad architecture, too little abstraction forcing repetition, and just bad writing.
NIH or Resume-Driven Development might be another way.
From personal experience, I worked with a team years ago where product owners wanted a datetime picker or parser for an app we had built. Senior dev on team decided it would be cool if it included some lite NLP. When product owners heard from him how easy it would be to add, they were on board.
He started with a popular existing Python library. But there was a bug with one corner case that was causing problems. So he took the initiative to spend a few extra days on the story to write his own simple NLP date parser.
A couple months later, early on Jan 1st, the new feature wished our ops team Happy New Year by taking down our application.
I happened to open an issue for the library's bug on Github after learning about it from the other dev. The owner there promptly responded to share a simple workaround for the issue. But by that time we already had too much software on our hands.
I think "Too much software" comes from product and engineers not being willing to say 'no' to feature requests and product bloat, rather than any sort of strictly technical thing.
If your product or tool lacks a clear focus and goal, then the code base will reflect that, and will grow and sprawl endlessly.
I have been net negative lines of code for the month more than once, while productively adding more features and fixing bugs. There is a lot of code out there that need not exist at all.
Either can be a problem. Too much abstraction and you're writing FooFactoryFactoryFactory. Too little, and you're repeating yourself. Somewhere between the extremes is a sweet spot.
The problem is that, as the project continues over time, the sweet spot moves...
Nah. It's always about 4 layers. Hardware/services/data stores/etc, wrappers/models/components, business logic / application, ops/deploy.
If you nest your models/components deep enough that they're forming new abstraction layers, you're nesting them too deep. Backup and use mixin-style stuff instead.
If your business logic or application are nesting pretty much at all, then you haven't succeeded at making good choices in your models/components.
Agreed, and I’d add that code duplication is hardly a big problem. It’s kind of like if I legitimately see a lot of code duplication, then I have enough data points to do the right thing. On the other hand, abstracting early to avoid code duplication is worse.
Hmm... I think you might be right. Or, at least, that the problem that is and the problems that go with code duplication are easier to resolve than those that show up with shit abstraction.
Maybe... Duplication is a code smell, but shit abstraction is a code problem...?
This reminds me of:
> Eat food, not too much, mostly plants > > -- Michael Pollan
My new mantra: Write software, not too much, mostly functions.