You are here: Home / 80-90+% of projects and companies don't need 100% custom-coding!

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

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

Welcome to the 21st century! Or have we regressed back to the 20th?

There is a disturbing increase in the number of custom-coding for a lot of projects, which had its place in the 70s, 80s, 90s, and maybe the early 2000s. But since about 2004 or so, is increasingly foolish.

For some of the newer technology adoptions (like some forms of blockchain, or what folks are now calling "AI") there can be some ironic argument made at the low-level for custom-coding (to me it is an irony to be custom-coding "AI"). However, for most projects (yes even the blockchain and AI ones), in the 2020s, most projects shouldn't need more than 10-20% custom code anymore.

Unfortunately, for the past 10-15 years there has been a growing trend regressing back to custom-coding most/everything.

Many of these people argue it is for job-security, though they don't understand they are accelerating their replacement by AI when they take that approach.

There are legitimate new "inventions" that absolutely require a large percentage of custom-code, but those too are likely only 10-20% of projects (generously - from what I see, it is more like 3-5% perhaps).

This is a ludicrous and disappointing regression trend, and in most cases monumental waste of time and money. Around 80-90%% of the time spent is completely unnecessary and very unwise from a scaling, maintenance, and security perspective. Even much of the project management, program languages, coding styles, etc. have all sadly regressed to the flawed parts of 1970s/80s thinking. Also ironically, at the same time, many of these groups/projects/people reject all the good things that worked from the 1970s, 80s, 90s, and early  2000s, convinced they have a shiny new way that will work better (and 99% of the time they are wrong, though those 1% ideas are gold!).

Unfortunately most new developers (80/20 or 90/10 again?) that started learning to code around 2010-2014 onward  have been in this worsening downward regression spiral to the 1970s (and worse since there was far better education and arguably higher IQs then) but with a disturbing increase in the lack of discipline, training, experience, education, intelligence, methodology, scalability, maintainability, security, and overall 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).

I have repeatedly delivered production-grade projects that were either completely bug-free or nearly bug-free, and done so over multiple iterations for versions 1.x, 2x, 3.x (that's my record so far, not quite made it all the way to 4.x bug-free production releases), while still accelerating PDLC/SDLC releases and increasing efficiencies by upwards of 400% in some cases, while reducing infrastructure and development costs by up to 90%. This isn't a one-time example, I have achieved along these lines multiple times over the decades. I win-some lose-some, depending heavily on the project's resources of course, but the methodologies, when allowed to be fully implemented, are highly successful. And I didn't create them, they were well worked out by many others far smarter than I, but I was happy and willing to learn from my "elders", soaking up as much "wisdom" from them as I could, and over time I benefited immensely by building on their knowledge, and adding another incremental layer to it.

A very large percentage of these failures are because of the current attitude of rejecting everything that came before, and assuming it had no value, and that only what is new has value, and that old is automatically useless. This is severely flawed thinking, but has unfortunately become increasingly ubiquitous in the IT industry (and elsewhere of course). This, more than anything, is what will likely accelerate adoption of AI and Robotics to replace all of these people that went down this regression spiral.

When you reject everything that came before you without regard to value (or values), then you make all the mistakes al lover again that millions (billions) of others did before you, and you set the human race's advancement back dramatically.

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):

Filed under:
Navigation