I have developed, in 30 years of programming, to a much more radical position. Technical debt and mounting complexity are major problems, and I want to see a splinter movement within programming that defies the contemporary orthodoxy on how to solve these problems.
Object Oriented Programming is not a solution.
Refactoring is a failure as a solution. INSTEAD: We need to say "NO," from the get-go, to unnecessary technologies. Yes, refactoring is needed, but we've been talking about refactoring for decades now, and we still have so many problems. We need to say "NO" to new technologies, wholesale; To be much more skeptical and dubious of technologies. Don't import a whole system, when you're only really using only 1% of the technology in it. I see so many technologies in use in workplaces, where only 1% of the functionality is needed. (I'm looking at you, Celery.) These massive systems have security flaws, bugs, and inflexibilities, that require custom patching and regular necessary upgrading and updating. They are built on top of other massive systems that have security flaws, bugs, and also require patching and updating. Yet because of "We don't want to implement something that someone else has already implemented better, and actively maintains for us," I see decisions made to get the huge big massive honking thing that ** isn't actually needed. **
When you have 10,000s of lines of glue code, to glue your systems together, and you're actively maintaining them against one another, ... and the alternative was to write a 500 line program that would do EXACTLY what you want, and is easy to modify and understand, ... ... something has gone horribly, horribly wrong.
When you're sending massive REST calls in series, with HTTP headers and payloads and everythings, ... ...when a single maintained TCP stream would do just fine, sending 4-byte packets back and forth, ... ... something has gone horribly, horribly wrong.
I said above that Object Oriented programming is not the solution. I maintain that. I think we need to seriously re-evaluate what the heck we're doing. I propose that we look at the notations we are using in writing programs. Forth has a radically different notation. APL has a radically different notation. There is great expressive power in these systems. They are compact and powerful. I have come to see that smallness is a great virtue -- not baroqueness.
A great **design** can make a dramatically smaller technology footprint. We're so focused on agile methods, that we don't see that a design can have a dramatic minimizing power. It's not about waterfall. Designs can be iterated after all. If the design has a small footprint, modification is quick and easy. The entire program can be rewritten in a reasonable time, if the design is little.
I am not writing this to convince anybody. Rather, I am writing this so that fellow programmers who resonate with what I'm saying are encouraged. These ideas are very much in the minority, and are drowned out by the mainstream orthodoxy of programming. But I believe that serious programmers who have been looking at what is going on can recognize what I'm saying here. I would like to see more expression of challenge to the orthodoxy here.
My Pointers for more information, for the interested:
* deep study of Chuck Moore's ideas on programming
* Alan Kay's ideas on programming
* the design of the TempleOS, which is extraordinary and powerful while minimal
* "Software Survivalism" and "Neo-Retro Computing" (Sam Falvo)