In the early 2000s, a lot of learning happening on IRC. You’d befriend a few people, and we’d all teach each other something that we know or have learnt. From writing small games in GameMaker (now part of YoYo Games) to writing extensions in C++ and assembly, there were kids who were practically doing everything. Actually, that’s where I first heard about neural networks, though I didn’t study it in detail.
Back then for me, programming was about creating something. Today, it’s spent inside the IDE wrestling problems that are not even related to the domain, like endless code organization, naming stuff, etc. These kind of secondary problems are fun when we’re still learning aspects of programming/software engineering, but later, they become an annoyance.
This dealing with code that’s not directly related to your domain is what I call code oriented programming. If the data that you’re dealing with is the hero of your code, then I call that data oriented programming.
In this Clojure Made Simple talk, Rich Hickey mentions this concept:
The majority of functions in Clojure just take data, and by data I mean immutable, unadorned stuff, and they return that same thing. A giant library of functions. Hundreds and hundreds and hundreds of data manipulation functions, ready to go. They take data. They return data.
So if you have anything that is data, you can use all those functions on it, which tends to press you towards making everything data.
-Rich Hickey in Clojure Made Simple (source)
Today, especially in frameworks like Ruby on Rails, the database is so coupled to the application that the application drives the data structures, not the other way around. Things like “polymorphic relationships” are easy and fun to have until you have to break the monolith and a service uses something other than Ruby. I remember the endless integrity problems that I ran into because developers did not know that a relationship in Rails does not mean a FK constraint.
Even as early as 2012, my friend and I would spend time designing the database more than we spent designing the application. But now, in just a few years, the situation has reversed.
I would not say it’s worse today. Code oriented development can be very good for a lot of tools, but as soon as you become an enterprise that is going to be around for ages, then thinking data oriented becomes a very valuable option. Your code would evolve, but the information conveyed by your data evolves much slower than that and unfortunately has more rigidity.