80-90+% of projects and companies don't need 100% custom-coding!

Welcome to the 21st century! Or is it the 1970s? Unfortunately in recent years there is a ludicrous regression back to 1970s & 80s outdated thinking, with around 80-90+% of custom-coded projects completely unnecessary to be custom-coded.

Welcome to the 21st century! Custom-coding a lot of project it had its place in the 70s, 80s, 90s, and maybe the early 2000s. For some few newer technologies (like what folks are now calling "AI") there can be some ironic argument made at the low-level. However, for most other projects of the past 10-15 years there has been a growing trend regressing back to custom-coding most/everything.

This is a ludicrous regression and in most cases a waste of time and money, and around 80-90%% of the time completely unnecessary and very unwise. Even much of the project management, program languages, coding styles, etc. have all sadly regressed to 1970s/80s thinking.

Unfortunately new developers that started learning to code since around 2010-2014 onward have been regressing to the 1970s but with a disturbingly increasing lack of discipline, training, experience, education, and comprehension.

Most egregiously they have reverted back to an increasingly blatant disregard for documentation and design, pushing more "code-first", 90% coding and maybe (if you are lucky) 10% shoe-horned-in documentation after the fact (at best), losing sight of the decades of proven to be effective design and coding principles. They have all but scrapped everything learned from millions of developers prior to the past 10-15 years, and are now repeating the mistakes of many decades ago (a la 1970s and 1980s).

So far, for projects run and developed by people who started working in tech around 2010+ increasingly over 90% of the custom-coded projects I have seen (and I've been looking at code for over 40 years), has increasingly become terrible spaghetti code. While 80-90% of the currently mostly/entirely custom-coded projects probably didn't need to be custom-coded, what is worse is that total regression in project and code quality in the past 10-15 years. *

This may in part be due to the reversal of the Flynn Effect since 1975, and also some of the more recent culture wars of the past 10-15 years, especially the extreme escalation of ageism and the increasingly disturbing and self-immolating automatic refusal to learn from the past, blindly re-starting the overall collective humanity learning cycle all over again from scratch, repeating all the same mistakes of the past (likely a mixture of all the above plus other factors to pile on, as if those weren't bad enough by themselves).

Sadly, developers with experience from only the past 10-15 years or so now just try to solve this by throwing more cloud resources at it rather than clean up their horrible mess (proper refactoring principles), or better yet taking what they have learned from their mistakes and throwing their "MVP" code in the dumpster where it belongs, and starting over with a much more sustainable design-first approach (80% design, 20% code). They refuse to learn from their prior mistakes, and keep repeating the same ones over and over, spreading their mess and infecting others under them.

And now they are undermining the decades of progress made thanks to open source, and sabotaging all of those principles and benefits, leading to making this problem that much worse.

I have directly and indirectly managed thousands of developers in my lifetime, with development teams anywhere from just me, to 35+ in most cases per project, and some times with over 200 in especially large projects/organization (not counting all of the other very important SysOps, DBAs, etc doing what the coders can't or won't do, more on the systems side instead of the new platform building side).

In recent years I am increasingly finding myself in a downsizing phase for the development teams.

So many code bases have become so entangled, and the teams trying to unravel them so bloated, in recent years at so many companies because of being terribly mislead about what should be custom-coded, and what is already available as "off the shelf" products or services, commercially, in the cloud, or from open source.

I have helped many clients over the decades get away from the "trap" of 100% custom-coded platforms, that don't scale, are severely insecure, and take much longer for time-to-market.

Instead I help them move to more of a model of conglomerations of multiple off-the-shelf (usually open source) solutions that better meet their scope and needs. This is generally the best approach for about 80% of the companies and projects I've seen from bootstrapped unfunded startups, funded startups, SMBs through multinational top Fortune-listed enterprises, and everything in between.

Every now and then there is something really truly new, that does need 80% custom code, but even those can be adjusted, for example, do you really need to custom code yet another CMS? Or can you use something that provides those functions already for you, supported by a large community, and you can focus instead on all of the underlying original, innovative, "secret sauce" code that makes your product/service/organization distinctive?

I have done this for many individuals and organizations.

I have literally directly saved saved them millions in development costs. And in many cases made it possible for them to get full 1.0 (forget just MVP) out the door in weeks or just a few months, for 1/100th cost it would have been for custom-coding!

Of course, this it is critically important to have clearly documented scope about the actual needs to determine if this methodology actually makes sense.

Sometimes (as I stated, maybe 20% of the time) custom-coding is really the best solution, but about 80% of the time it does not.

This approach of recommending that you "don't reinvent the wheel from scratch" in areas that aren't relevant to the company's innovative market leadership, and taking this most-off-the-shelf approach and then just "Gluing" or customizing the last 10-20% that is specific to the scope that makes their product/service/organization stand out from the crowd, as the organization's "secret sauce", is a much better approach most of the time.

This is a more effective, faster, scalable, and all around better approach (for about 80% of companies/projects).

This has been effective in reducing bloated dev teams of 30+, or even over 200 developers, down to generally a more reasonable 2-6 with far better quality, scalability, security, performance, and long-term manageable results.

This is generally a much faster time to market approach as well.

* I have been online and hands-on coding since the late 1970s, and these provides an overview perspective spanning 40+ years seeing trends and cycles repeat themselves again and again. I bring up the "universalisms" that help can make or break endeavors from time to time in my articles, just a few related to these topics, including short-sighted sabotage of the whole open source movement and best-practices for projects and coding, include these (if you must custom-code):