Here comes your millennial diagnosis of a hype word filled architecture and how its affecting me:

I was diagnosed with a mentally and socially crippling degree of OCD at a young age. As I got older and away from areas that contain hundreds of people on daily basis, my tendencies resided but still manifest themselves in lesser ways. Over the last 8 years of development, I've taught myself to steer these compulsive tendencies into the art of software architecture and code quality.

Over the last 3 years Ive become more obsessed with the concept of designing agnostic, pluggable pieces that are weighed down by very few dependencies. I had not read any books on pluggable architecture or dove deep into what SOLID means to me. It just "naturally" felt like an evolutionary step in where my software quality needed to go. I had never approached microservice architecture and at the time knew little of it so instead I went as far as breaking php or node components up into their own packages on npm/packagist. Making packages of them was as far as I could go to assure my components were entirely plug and play. It helped my mind understand them as separate entities and devs after me know that they in no way could depend on my core suite of services.

Then I ran into this "Clean architecture" book and my initial reaction through out it was "hmm, this is a much better way of achieving what I've organically been coming to". Inverted dependency was new to me. I had heard it a thousand times but never put it to practice. I approached agnostic behavior by much harder means of separating binaries into their own address spaces or combining them from different binaries to run in synchrony. The idea of pushing hard decisions off and separating concerns through interfaces was an eye opener but my it still does not solve the issue of monster repos.

I don't understand how teams allow services to grow exponentially with little check and Idk want to know. It doesnt take a principle dev with 20 years experience to say "this shits starting to get out of hand, lets split it". The minute you are forced to use your IDE's global search to work efficiently within the code base, it's too late. As silly as separating a project by npm packages sounds, it still was just a logical means of breaking up something far too complex so that it doesnt get in its own way.

Then came micro-services or my final realization of it. Ive found a perfect placement that satisfies my own compulsion for cleanliness between the principles of clean arch (or onion, or port arch) and service oriented arch. Teams work well within small codebases. They work well with low dependencies. They work well in a suite of services that can be plucked and rewritten without cascading dependencies to consider. Teams work well when given hard http specs to abide by when talking with other services or with a gateway.

Now someone tell me where in the flipping fuck I can work where these architectures are taken advantage of. Ive been through 3 companies in three years and each has been a shit show of monolithic web apps, mono api's. Shit our last suite thats now sunsetted was 600k lines of vanilla php, no framework, no orm, different approaches to architecture that did not unify, high dependencies, one repo.

The biggest thing coming out of that for me was knowing what I despise in architecture. Having these horror stories to pass on forever when discussing our bright futures. Im rambling now but I suppose that becomes the closure needed for this ted talk. Going through hell and coming out with a lesson learned. Feeding my mental disadvantages in life with best practices in my career.

  • 1
    Kinda similar boat, ADHD and have had a mixed bag of jobs. Thinking about going my own way.
Add Comment