Sometimes I create a solution to a simple problem. However instead of making use of the solution, I keep extending it unnecessarily. This is why for this kind of project, I want to systematically restrain my future self from adding new features beyond the initial vision e.g. by actively refusing generic and re-usable code.
What is the search engine friendly term for this approach or at least for this situation? “Ad-hoc programming” may be literally what I’m talking about, but in practice it’s associated with unplanned happenings.
- Develop your project on a temporary filesystem until it has the desired functionality.
- Move the compiled binary to a persistent filesystem.
- Reboot.
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.
e.g. by actively refusing generic and re-usable code.
I don’t think that’s the solution to your problem.
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.
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
.Suckless?
If you’re looking for some search terms, you’re looking for the Unix philosophy, and Unix pipelines and command line patterns.
deleted by creator
I use mostly Rust. I meant “extending” in terms of features.