Published on

Dogmatic engineers and a product

Authors
Attention #1!

Please remember to take a pinch of salt with you while going through this tale!

Attention #2!

This tale is based on Blind men and an elephant

A problem

A group of engineers met to provide a solution to a certain business problem.

One could say the need was to build a product for a specific area of human activity.

They started debating about the problem, solutions, loudly analyzing and providing opinions regarding them.

Domain-centric

The first engineer belonged to a "Domain-Driven Church" and immediately started voicing his perspective:

Discussion
Domain-centric Engineer:This thing is full of the specific language - terms, concepts and words. It carries a specific meaning we need to discover. Maybe even invent, that's the fact. Regarding facts, what are important events happening through its lifetime? When we will discuss all of those, we must constantly remind ourselves about boundaries - then we will be able to identify already mentioned language and design value objects, aggregates and sagas. When do we start Event Storming?

Data-centric

After this little speech, the second engineer that cared only about the data begun his turn:

Discussion
Data-centric Engineer:This thing contains a massive amount of information, very granular details how we can describe it. What are relationships between all of those information? What contains what? As I sense it, some data is pretty stable and cold, other is very much ever-changing and hot. Let's not forget about very important aspects like performance when storing or restoring information - are there any constraints we need to apply? Please remember about normalization and redundant details removal! What will be a database schema? Did anyone make Entity Relationship diagram?

UI-centric

The third engineer suddenly started screaming politely:

Discussion
UI-centric Engineer:This thing for sure is going to be used by real people, end users. What about them? We need to make their experience delightful and supportive. They shouldn't spend time staring at loading screens full of spinners! What's more, they should be guided through out the whole journey, all the confusion and doubts should cease to exist when looking at beautifully crafted user interfaces! To achieve so, we need to pick SPA and modern front-end tools. Do we have any low-fidelity wireframes and mock-ups? React or React?

Process-centric

The fourth engineer calmly stood and threw his speech:

Discussion
Process-centric Engineer:This thing seems to have steps that take some time and occur in specific moments. All of these require integrating with various parties and collaboring with many downstream and upstream services. We should start modeling all of these before we actually write a single line of code. For sure there are off the shelf tools that will help generate code from our process models, so that we will be able spend more time on analyzing dependencies. Where are our BPMNs artifacts?

Platform-centric

The last, fifth engineer waited for his moment so when the time came he closed the whole discussion with the following words:

Discussion
Platform-centric Engineer:This thing, in order to run, requires hosting. Even though it might start as a tiny thing, it will grow. How do we provide enough resources to achieve so? What's more, it needs to run in secure environment, but before that we need to have deployment and release pipelines, with full automation - having so, we will scale development and ensure development teams are focusing on building things that matter, and not delve into infrastructure details. Can we pre-decide how many nodes should be in our k8s cluster?

A solution

How easy it is to apply lenses and deeply focus on one particular aspect, when designing?

Designing is hard, difficult and effortful.

Solutions, serving the needs of the consumers, require time, thoughts, experiments, iterations and mistakes.

One could probably say that it's a role of an architect to provide multiple perspectives and keep and equally visible.

Engineers should "just" do what engineers suppose to do - implement. Ain't so, dear Reader?

Turns out things are more fluid and unpredictable when we organize human beings to conduct designing activities.

What was the first, an organization, a problem or a solution?

Epilogue

After hearing all of the perspectives, each engineer was both happy and sad.

Can you tell why, dear Reader?