Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities [email protected]
I would recommend just trying to cultivate a YAGNI mindset. I add a little more to the rationale - we are not very good at accurately predicting future requirements so rework/unraveling work becomes likely.
Following from there, trying to use technology (I could be misinterpreting but I think that's what you mean by "systematically restrain") is also going to be things you don't need.
Minimum viable product (MVP) is a term commonly used in project management. Typically it's approached from the perspective of "let's first do the work to meet the project requirements, and leave nice-to-have features as a stretch goal (i.e. only do it if the MVP is ahead of schedule). The antithesis of MVP is scope creep, which is what you seem to be suffering from.
Before I jump to "that's a really bad idea" with my 20+ years of experience: why?
I mean, sure, don't implement functionality you don't need, but making code not reusable intentionally? Why?
It definitely is and I wouldn't take this approach mid-way for a project with multiple users and contributors. But it works for my little projects that desperately need me to be the user more than the developer. An example would be a REST API with a few endpoints where the database operations are handled directly in the route handlers uniquely for that specific task.
An example would be a REST API with a few endpoints where the database operations are handled directly in the route handlers uniquely for that specific task.
That's a prime example for untestable code (not testable with unit tests/without IO). That might be fine for a tiny experiment, but I'd advise against it for projects of any size, even private ones. Always use a model like MVC, MVVM, three layers (data, business, user) ...
I feel like we should have an in depth talk to better understand the problems you're facing and the line of thinking that motivates your initial request. Unfortunately I currently do not have the time for that. The best I can do now, with the best of intentions, is to advise you to read literature about software development. The trouble is, that I'm not sure what to suggest, because I think there's nothing that fits your premise. Maybe read about library development/reusable code so you better understand what not to make reusable by comparison? So maybe "Reusable Software: The Base Object-oriented Component Libraries" by Bertrand Myer or "Analysis Patterns: Reusable Object Models" by Martin Fowler. Though, both books are more on the old-fashioned side and I wouldn't recommend them if you're not an avid reader and (former) student of computer science.
Thanks for the recommendations. A missing understanding of what needs to be reusable could be a problem. E.g. in my example when I add a DAO-like interface just to implement it for the two entities I have, I invite my future self to add unnecessary features to make more use of that interface and other generic components.
Organizationally, you don't want your API handler to care about implementation details like database queries. All DB interaction should be abstracted into a separate layer.
Generally API handlers only care about injecting any "global" dependencies (like a database object), extracting the request payload, and dispatching into some lower-level method.
None of this requires generic code. It's just about having a clear separation of concerns, and this can lead to more reusable and testable code.
But I do choose this approach for these problems to not have reusable code on purpose xD I'm not try-harding to rewrite everything for every feature separately, so most of it would be separated and modular, as long as it's required by the initial purpose of the software. However I avoid writing generic and reusable code that only gets rewarded with functional scalability in mind.
And unit testing is honestly not on my list for these kinds of projects. At best I'd write integration tests to challenge the route handlers. But simply using the software is sufficient to cover the predictably unpredictable usage in these cases.
idk if this is a programming specific question. It feels more like "perfectionism" or a low-level OCD. For the programming piece, using some sort of task tracking system might be helpful. For example, after a task has been completed (aka a solution was found), move on to the next predefined task.
Another vaguely related term: premature optimization
On a similar way I was thinking of saying that the solution is discipline. But I didn't do it straightaway because I could see it easily misunderstood.
Yes, the better solution is probably not on the programming layer :D I was still interested in a specific term to this approach to look up to what extent somebody can drive this.
e.g. by actively refusing generic and re-usable code.
I don't think that's the solution to your problem.
Many of an engineering bent, including programmers / coders / developers / whatever we're called this week, have an innate desire to tinker with things and add "just one more feature". This is known as "feature creep" as more and more metaphorical little bells and whistles are added. See also: "Bells and whistles" itself, "creeping featurism", "feeping creatures" (ho-ho), and variants thereof.
Searching some of those actually finds other terms that other responders have mentioned.
Most of my stuff over the years has been hobby or job-adjacent rather than my actual job to produce the tools I did, so I think what really helped me to stop working on the very few things that were requested by other people was not being a user of the tool I created.
I still had to "use" things to test them, but once they were in real use, I didn't have to see them all the time and think "I could just add this little thing here / there / etc."
It was only at the request of the users that specific new features were added.
Getting someone else to design the interface is often helpful, assuming they're not an absolute fool.
A few years later, a very similar tool I made, one that I was a user of, got a lot more tinkering and feature churn. Maintaining backwards compatibility reigned some of that in, but there were a couple of times where that wasn't possible.
Thank you! That's exactly what I need, but I probably have a unique case where I as the developer am the cause for the feature creep myself. For work, luckily our product is an ERP software, so in most cases I'm naturally uninterested for more features :D
Sounds like the unix philosophy of small tools that do one thing and can be plugged together via pipes.
Make a well designed public interface and make the classes final.
The unix philosophy is about making highly reusable and pluggable tools which is the exact opposite of what OP is asking for.
If you're looking for some search terms, you're looking for the Unix philosophy, and Unix pipelines and command line patterns.
