I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
I work on more than one web site at a time, all using the same base in-house library toolkit. For each of these sites, they all take a slightly different approach to solving various problems, sometimes related or sometimes not. Once two independent solutions emerge that look like they may be related, the two are pitted against one-another, and then merged together into a single solution, and then pushed into the core toolkit for the rest of the systems to have available as well. This method of parallel development has created significantly better software, because it forces multiple approaches to problems, rather than just a single approach.
The philosophy has been mostly the same as you suggest though, WET rather than DRY. If something is done once? Cool. If it is done twice? Odds are each one will have different advantages and disadvantages. When it comes to doing it a third time, the first two are merged into a single piece of code along with the new requirements, and pushed to the core library.
Doing this, I now have an extremely robust data processing system, user authentication system, path router, HTML templating system, and more all ready to go for future projects.
I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
Yup, that's exactly it! And the entire framework is full open source BSD licenced on my GitHub account. The main issue is lack of documentation. This has been one of my main focuses this year and into next.
I work on more than one web site at a time, all using the same base in-house library toolkit. For each of these sites, they all take a slightly different approach to solving various problems, sometimes related or sometimes not. Once two independent solutions emerge that look like they may be related, the two are pitted against one-another, and then merged together into a single solution, and then pushed into the core toolkit for the rest of the systems to have available as well. This method of parallel development has created significantly better software, because it forces multiple approaches to problems, rather than just a single approach.
The philosophy has been mostly the same as you suggest though, WET rather than DRY. If something is done once? Cool. If it is done twice? Odds are each one will have different advantages and disadvantages. When it comes to doing it a third time, the first two are merged into a single piece of code along with the new requirements, and pushed to the core library.
Doing this, I now have an extremely robust data processing system, user authentication system, path router, HTML templating system, and more all ready to go for future projects.
You're basically building your own framework out of your own business requirements, sweet! :)
Yup, that's exactly it! And the entire framework is full open source BSD licenced on my GitHub account. The main issue is lack of documentation. This has been one of my main focuses this year and into next.
Good luck, after all that's how both Django and Rails started. They were frameworks used internally in companies
In 2019 we plan on experimentally standing up more instances of the underlying platform that powers dev.to (Emphasis on experimentally)
I'm really excited to see what could come out of extracting this very high-level, highly opinionated framework for building online community spaces.