4 ms·
You've found a way to correctly anticipate new user needs and new technologies years, even decades, in advance? And you've found a way to completely forestall
by petsfed 2y ago
You've found a way to correctly anticipate new user needs and new technologies years, even decades, in advance?
And you've found a way to completely forestall the non-technical demands that force non-ideal design choices?
You're sitting on a gold mine friend.
- ninetyninenine 2y agoI should say not prevent it. But minimize it in the maximum possible way. I am sitting on a gold mine. But I can’t prove it. That’s the problem with this stuff. The industry moves horizontally with each design such that nobody knows if say the current design trend was better than the last. We go better or we go worse and nobody knows if it actually was. Maybe I am sitting on a gold mine. The problem is you’d never know about it. You’d never believe it. Because a proof isn’t possible. So because it’s not provable you have no clue about any design whether one is better or one is worse and thus you disbelieve everything. The overall question is how do you create a design or pattern that has maximum adaptability to anticipate any possible requirement change with minimal rewrites? Where you only swap in and swap out modules without changing structure? I think I found the best possible way. But you won’t believe me.
- quickslowdown 2y agoI'm not the OP, but I'll say that I don't believe you, because you're telling me you have The Perfect Solution, without providing even a hint of what that solution is. If I was skeptical at first, I'm now certain you're selling smoke & mirrors until you provide any evidence at all you actually have an idea here.
- ninetyninenine 2y agoI literally said I don’t have a perfect solution and that you wouldn’t believe me. What I have is the best possible solution based on available solutions that we know of. I found the best way.
- progmetaldev 2y agoI understand what you are saying. Obviously the type of development you do is a factor, as well as the way you and/or your team does development. I think others are looking for the one true solution, and you are saying that you have found the solution that works for you, given the way you develop and the constraints you deal with. At least that was my understanding of it. If you are doing embedded development, being thrown into a large front-end development project isn't going to use the same solution. I have a solution for custom content management systems that usually makes it fairly easy for me to incorporate customer requests without needing to toss out my existing solution and start over. Almost a type of framework built over an existing open source CMS product. I maintain about 90 websites as the only backend developer, and have spent about 12 years now working through various versions of the software to custom tailor a solution that works for nearly all situations I have come across. I don't do front-end development any longer, but I was involved heavily at the beginning stages to make sure both the front-end and backend were flexible and broken apart into modules.
- ninetyninenine 2y agoNo im saying i have a general solution for everyone. The general part only applies to the part where are software projects are similar. The part where they are dissimilar it can’t apply. It’s impossible to generalize over distinctly different things but I found a solution that generalizes over what’s similar in the overwhelming majority of projects. If you find a templates solution works for you then that is not a general solution. It’s better for you but you are hardening and becoming opinionated on certain details and that works for what you’re working on. My solution is a lower level pattern that is more general and less opinionated. For what you do it likely is only effective if you are required to drastically change an existing project while maintaining as much existing code as possible. The solution prevents a complete rewrite and allows you to modularly pull out what you don’t need and replace with the things you do need. If you don’t need 90 percent of your project this pattern won’t prevent that. What this pattern allows is for you to actually pull out that 90 percent. Many projects that only need you to pull out say 30 to 40 percent of it actually end up with a full rewrite because the modules aren’t decoupled enough.