white ceramic mug near tea pot on table

It’s not just about learning a programming language

It’s actually teaching yourself a way to think … I found myself today in a situation at work that’s outlined perfectly in this article on strategic domain driven design. In fact, the original idea I remembered it from Eric Evan’s great DDD book, but I couldn’t quickly find the page and paragraphs that contained the idea of contexts and upstream/downstream systems so I relied on Google to find me a relevant authority to invoke. Luckily, the above article came about and it captured the idea I wanted to express to my co-workers perfectly.

The situation was that an upstream data producer made a deployment, to which we scaled effectively and nicely all in an automated fashion but then a day later, they rolled-back the change as it produced 50% extra data. Then at the roll-back, 50% of the data was gone.

The problem is neither the change, not even the rollback itself, as the system I was owning scaled linearly with the input traffic data so it would scale EMR clusters (the thing it runs the processing jobs on) based on a strategy that computes a GB/core formula and scales as needed.

What happened is that the rollback was done almost instantly, dropping 50% of traffic in a few minutes, in any case, in less than an hour. Note that the set-up we’re in we don’t have any kind of back-pressure or downstream notification of traffic variations, so any downstream systems kind of needs to adapt dynamically as it sees fit to traffic changes one way or another.

Since our logic scaled up OK with the traffic, it didn’t scale that with the traffic as it relies on scanning the current hour of data and merging current and previous hours (based on the UPSERT functionality in the delta.io library). Thus, when the roll-back was done, the next hour had 50% less data, leading to a 50% less cluster, leading to insufficient resources to pass processing over that specific hour.

Now I don’t mind such changes but what happened and what’s the subject of this ranting blog post is that we, in general, as a software development field fail to communicate. What happened actually, the root-cause of all the problems that stole a day from my life was simple. Poor communication.

Someone did a change (and a rollback) in an upstream system and failed to communicate the impact in downstream systems. As so, downstream systems suffered, one of which was mine, luckily only in 10% of the full deployment we have.

I’ve been developing software for the best of 15 years, both freelancing and hired and what I see from month to month, year to year is a degradation of the quality of software development as a field. I feel people that are joining the ranks of seasoned developers are only learning a language, landing a job and stopping there.

I feel more and more as nobody is interested in design, proper design of any kind (systems, domain) and people tend to want ‘to code’. Whereas this is an industry in which we are paid firstly to think and then to express that thinking in code, preferably in as less code as possible to keep the business idea we’re resolving understandable (for the next developer also).

A great deal of work being a software developer is communication. Not just coding. Your code, the thing that you write gets deployed into an environment. Synonyms for environment are also “eco-system”. That means, the thing which you are changing affects the eco-system in which it gets deployed. If it does so, you have a moral obligation if nothing else to communicate the changes so that the liaisons to your system react accordingly and adapt.

Software is about modelling a domain. And a domain imposes a context (preferably bounded). The context does not exist alone and unless you have a tiny application and 100% control of all your aspects of your deployment, yet that’s not the case when the team grows from +1 developer up.

Thus, understanding the fact that you work in a domain, in a bounded context, you should, as a software developer do more than just code, test and deploy but also communicate and try to understand how systems upstream and downstream are affected by the changes you bring forth.

To be honest, Eric’s book was released in 2003. That’s more than 17 years ago given today were in 2020. When something passes the ‘test of time’ such as this book and its ideas and are repeated time and time again, then it’s probably best to introduce that knowledge a a discipline in university courses so that a new generation of software developers comes forth with a refreshed way of thinking, one grounded in good principles, not just one built upon the idea of knowing a language.

It’ simple. To make an analogy, it’s like learning any kind of Asian language (Chinese, Japanese, pick your poison). You may know the language but that doesn’t mean you understand the culture …

And for Asian people, last I checked they cared much about their culture, not just the act of speaking their language.