Fairies do not exist, that’s a fact. But fairy tales are other meat, they bring a fantasy into reality fleshed in the form of movies, books, crib stories etc… and people, from early stages, believe in those fantasies until they grow adult enough to put it behind and embrace real life avatars.

Software creation is like that fairy tale we can never manage to give up to. We believe the story and, somehow, we don’t want to put it aside when the right moment pops up in favor of new approaches in the long way of growth as developer.

Things pictured out crudely

This is an important ground so I’m gonna go straight to the point.

It’s not new the mistrust that I practice when it comes to Frameworks and, especially, those magical solutions many developers assume might come out of blindly using it with no measurement, especially when rich Domain involved.

I don’t like coming down into technical details on this blog’s articles and I’ll try to keep the leaning on this one, however I’d like make some specific points on this so I’d place more understanding.

A little bit of context

A couple of years ago I was discussing with colleagues about a solution implemented by our team and the reasons of our design. The thing was about a Single Sing On integration with external Identity Provider and the reasons of, within this context, why we end up following a Command-Bus approach to our design.

There was the need to implement a solution that included a Customer management logic around IdP responses, there were different contexts where the SSO could be called from and others used upon its completion, there also were more Entities involved in the Domain like Customer Address, not gonna enter into Domain policies/constraints though.

The fact was that a lot of business rules were implied outside the boundaries of Magento(the framework we were using) so its constraints and machinery were not sufficient, at least for our goals of making something testable/scalable/maintainable.

Hanging on Childhood Fairy Tale

Regarding the solution, the point of discussion was on: why following uncanny structure in the code that nobody understands. I was told of having gone off the rail on the solution cause introducing unnecessary components into it.

Core Disclaimer

Spitting code into a Controller/Model/Helper… is not a valid approach, on behalf of clean design, when the purpose is to create maintainable software and reduce Technical Debt.

That recipe is proven not to work in almost any case, especially when the Domain to model is big; on the contrary it increases to unthinkable levels Technical Debt. It’s kind of we are trying to find the way out from the forest but we only focus on the current tree, there is no way out from this approach, we need to broaden up the mindset in order to find the exit.

Normally the old mindset tends to import/include/use dependencies indiscriminately within a class without perceiving the big dependency/coupling being generated out of this bad practice. When a new business constraint/rule/policy comes out we just add more burden to the barrow and new(more than one) method/property is included so current class’s getting fatter hence.

This happens very often in today’s world, especially on Web Development ecosystems. This old approach is more in alignment with Imperative programming, the hows are the domain of the implementation details, not the high level design which actually governs the first ones.

It’s all about Narrative

So, the truth is that there is actually an authentic tale to this story, never best said. I’m gonna come down to expose my standpoint on such grounds since I consider Software Creation a Story worth telling the simplest possible way.

There is a narrative behind every Software modeling we’d rather urge to express the best way for the sake of our vested interests as Good Software Designers.

In a rapid glance, writing code is like telling a story. First of none is valid to say that the Author does not write the Story in one shot, there is a time for preparation of the drama, profiling the characters, picturing out the events, providing consistency to a set of basic components like the relationships between the characters, the timeline of the Story etc… All this happens previously to having the Novel written, even the first Draft, I would call it the process of creation. When the Writer counts with this micro-universe shaped, then he sits down and start Writing the first Draft.

The same thing would happen to Software Development. Developer does not(or should not) gather specs and right after that, puts his butt on the chair and start coding. I call this, the Syndrome of anxious Programmer, opens up IDE and begins to spit LoC within Framework’s conventional namespaces(Controller/Model/View…). From this time on, a try/error cycle begins in order to accomplish business needs.

There is no Story being told on this, if a external actor(Reviewer, Auditor …) would throw a stare at the solution, he wouldn’t say what the Story is about, in best of cases he’d be forced to read the whole code an try to guess to heaven.

There is no data nor service contracts, no own Design, no way to guess a design pattern being applied, no Test suites, no BDD, no TDD etc, just a bunch of code attached to Framework layout without own Life. And this is perfectly understandable, Frameworks know nothing about your Domain, this is the advantage of Developers over Frameworks, that we know them but they know nothing about our business being modeled.

If we manage to build this Narrative around our Domain model and create proper Story out of this, then our solution is relentlessly bound to success on grounds of adaptability, scalability, test-ability and Software resilience. Anyone outside our frontiers that reads our solution will understand perfectly the high level picture dwelling around.

Prologue

If really want to reduce Tech Debt, then first start shaping what you have to say about the current Domain. A house building process always begins from the ground, never from the roof so it’s time to set proper grounds for Houses to come.

Tell a Story worth reading in the quest of writing the best of our Novels and don’t forget that, unlike real authors, there is always room for improving the quality of our Novel but, that’s another Story.