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.
You must log in or # to comment.
- 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.
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.
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.
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.
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
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.
deleted by creator
If you’re looking for some search terms, you’re looking for the Unix philosophy, and Unix pipelines and command line patterns.
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.
