I have great respect for engineers who apply their minds into what they develop. In general, each and every one of us tries to solve a problem a bit differently than the rest. Some of us have quite an interesting approach that extends its influence on the rest of us. Shaping the methodology of which we attempt to solve similar problems in the future. These are the folks we call Computer Scientists and what they produce is what we call Algorithms.

In this day and age, and as the software industry and technology in general is advancing with the speed of light (still not fast enough) — the types of problems that we try to solve to create a true impact should also exponentially grow in its complexity.

The bigger the machine grows, the larger the dreams would grow too. And so are the problems that are needed to be solved to achieve these dreams.

We build stronger hardware, nano, and quantum technologies to tackle global problems and existential threats to the survival of the humankind and its evolution.

But, in a world of forever changing assumptions, variables and givens — I’ve learned that obsessing over deliverables, deadlines and business domain is just an occupation put there to keep non-engineers “busy” while the actual product is being built.

“Create as We Play”

I’ve also learned that it is much, much more beneficial to create and learn all at the same time. As long as there is a north star where engineers can aim to (for now) — there should be absolutely no shame of experimenting in different directions (and fail) to achieve that very goal.

A great article I read about the journey the developers of The Legend of Zelda — Breath of the Wild video game have described to explain how they focused more on the quality and value of their video game rather than hitting some deadline, here’s a quote from them:

“In re-examining the convention that Zelda games are played on a set path, we decided to implement a groundbreaking new play style that would allow players to go wherever and do whatever they want. This has been achieved for the first time in the history of the series in its newest edition, Breath of the Wild. In order to attain this goal, we spent most of the production time creating the game as we played it.

The process of “creating while playing” went like this: first, we placed a countless number of “points” throughout the vast world of Breath of the Wild. Then, as we went through and actually played the game, we would make those “points” larger, smaller, or move them around, incorporating the things that we felt, while playing deeper into the game itself. In truth, this production style is very similar to the method Miyamoto used in the very first The legend of Zelda. Nonetheless, as games became 3D and people wanted more realism from game worlds, it became necessary to have a concrete “blueprint” of our game world from the very start of development. In essence, what became known as the quintessential Zelda experience, following a path set by the developers from start to finish, ended up being a product of the demands placed on the developers by that blueprint.

However, since this approach of creating a game while actually playing it means that the game continues to grow and evolve over time, it makes it very difficult to decide where to place the ending. Even now, after development has finished, I still get the feeling that there are so many things left that we didn’t get a chance to achieve.

Although this feeling isn’t new to this particular work, for past games, it was more a feeling of disappointment.

For this game, in contrast, it’s more of a desire to keep evolving and growing. I feel like that’s a big difference between this Zelda game and previous versions.

I’m not sure what lies before us, but I’m positive that this feeling of wanting to keep on growing and changing will be a driving force for future Zelda games. I hope that you’ll keep your eye out for whatever comes next in Zelda.”

Eiji Aonuma’s idea of delivery wasn’t based on particular plans or deadlines but rather a level of quality that can’t be attained unless multiple attempts of trial and errors have taken place before that “sweet spot” is found to declare the development completed.

“Creating while we play” — seems the be the exact same idea that have driven a whole bunch of some of the greatest products out there. A true vibrant environment of experimentation seeking the ultimate experience that fits just what the target consumers are looking for.

But in order to create that kind of environment and embark on such a great journey — few principles have to be kept in mind to ensure the development doesn’t go off track. Here’s what these principles are:

Primitives First

In the age of modularity, single responsibilities, microservices and front-ends — it’s very important to understand that breaking out the components of some system while making sure these components are unaware of each other’s existence is the only assurance a particular product can survive the rapidly changing environment — especially in the software market.

For instance, building an e-commerce platform with modular components where an invoicing component knows too much about the payment component is not a generic way of building a product at all.

These components are what I call primitive components. They are like the elements in nature, they don’t specify or know about what can and cannot be created with them in combination with other elements. There’s absolutely nothing in the molecular structure of the element of aluminum that knows about the structure of stones.

Aluminum is a primitive component. It can be a part of making a foil, deodorants, antacids and many, many other products.

These primitive elements are nature’s way of teaching us that building systems, regardless of their complexities requires and mandates maintaining a level of primitiveness in the very structures of components of these systems.

Now, let’s look at it from 10,000 feet perspective. Building modular components or primitive modules will allow the fluid and successful restructuring of any system by rearranging and reassigning these components.

And with a focus on building these primitive systems, we would be able to orchestrate different combinations of these systems to support our current and hopefully future objectives.

Putting these primitive components together is what I call tailoring experiences — let’s talk about the tailors of experiences in the next section.

Tailors

In essence, software engineers are tailors. They tailor experiences to fit their end-users. An engineer cannot possibly tailor a truly impactful experience that “fits” if they are not in direct, recurring contact with end-users to understand where to place their focus and where to invest their time.

But tailoring experiences isn’t just about doing what is thought to be where the value is. Sometimes your end-users don’t really know what they want. Some experiences emerge from no current need or ask. Experiences that we today all use such as social media had no real ask in the software world at its early days.

Tailoring experiences is about connecting to people, then connecting people to solutions that helps them evolve, grow, and most importantly survive. Some experiences can be damaging, or negatively influencing — some others are inspiring and motivating — it all depends on what the purpose was when implementing these experiences and what end-users made it to be.

It is very common that some software could be used in a different direction compared to what the original inventors of what this software intended it to be. Sometimes software can be used in the exact opposite direction of where the software was intended to go.

But tailoring in and of itself needs to have its own level of primitiveness — the most primitive components in nature are still an orchestration of even finer components. The same logic shall apply to higher order advanced components that are considerably and relatively primitive to their orchestrators.

Maintaining a level of primitiveness to advanced components in any system shall guarantee complexity control. Complexity control equals maintainability, longevity and pluggability. The more advanced the components being built or tailored are, the more focused they become on a narrower and narrower objective. And that’s expected. In fact, its happening be design just like in nature, the closer we step towards a goal the clearer the picture of that goal becomes.

I say the picture of that goal, because it lends itself easily to the next topic of this article, which is the planning.

No Plan

In the enterprise world, sometimes we may run into situations where the quantity is more important than quality. That’s a poisonous idea that spawns from individuals who care more about their picture and their rewards than the true value they bring to the organizations where they work.

These individuals might have positions of power, where they start influencing the decision-making processes — injecting themselves into the design decisions that would inevitably land them in an even higher position of power and lands the rest of the engineers working on the very same project in a hell of pain trying to maintain half-baked product that follows no guidance or pattern.

When we as engineers declare “There’s No Plan” — this very term tends to send a wave of panic in higher ranks where the aforementioned reward-seeking individuals live. It’s a healthy panic because it quickly shows who is more focused on the quality of the product, versus those who are only focused on pushing half-baked software out the door to get to the next level of recognition. It’s all temporary and pathetic — but that’s a story for another day.

No plan means that we know where we are headed, but the step by step, hour by hour and deliverable by deliverable to get there is subject to change as the world is changing around the engineers tailoring the experience.

Think of any software project as a maze. You continue to bump into walls until you find the correct path to get to the final destination. And in the process, there will be a lot of trials and errors, these trails and these errors should be celebrated and considered as a part of the innovative progress not anything else.

In the real world, the maze keeps changing, so is the exit out of that maze. Following tradition rather than innovation might just be the worst possible decision to be made. Every system is different, it has its own circumstances, conditions, and goals — despite the fact things may seem similar at the beginning — it’s actually better to tackle them differently. It’s the only way for growth and innovation.

Don’t Follow the Rabbit

Declaring no plan while focusing on a north star where things should be headed is a healthy approach to build any enterprise application. Diverging from that goal into side doors and rabbit wholes that may or may not lead to the other end is the opposite side of the coin.

As much as there are people who want to push half-baked products out the door to fulfil a personal agenda of recognition. There are also those who idealize the world so much so that they can’t pull themselves out of an impossible idealistic vision that may never be achieved.

Idealists tend to drain their energies and spend their time chasing a mirage that can never be attained. In fact, these idealists might be the reason engineers end up with non-engineers leading their projects anyway. Simply because idealists portray a picture of a aimless (yet smart) engineer who doesn’t know when to stop searching and when to start developing.

Think about a group who were put in a maze — some of them are keeping an eye on the path, examining different possibilities. And some others are thinking only about themselves, they examine only the shortcuts only they could take to exit the maze, no worrying about others who they may leave behind. And then there are the third kind who are focusing more on the materials in which the maze was built, and maybe somehow without any tools they may evaporate it.

The first group are the doers — the visionaries who keep their eyes focused on the road and they learn and adjust and evolve as they navigate their way to pull everyone out of the maze.

The second group are the corner-cutters. They want to be known as the maze solvers at any cost. Even if everyone else behind them gets stuck and lost in that maze forever.

The third group are those who follow the rabbit down the hole. They slow themselves and everyone else down by overthinking every single step of the way. And while they may have the best intentions in their hearts, they can be just as negatively impactful to the whole group as the corner-cutters.

Sometimes the third group could a much more negative impact on the group than the corner-cutters. It all depends on the perspective and the long-term vision.

The First Group

But the first group are the ones keeping everyone in check. They don’t allow the corner-cutters to go all the way and hold them accountable for their selfish actions. While they keep pulling the overthinkers from every rabbit whole they dig themselves into. These are the entrepreneurial innovative engineers. They are the hope to take everyone, and I mean everyone to the final safe destination without leaving anyone behind. And despite those who may fail them, disappoint them, or doubt them — they continue to progress until the very end.

Because these engineers are the ones taking everyone to where they’ve already been. Taking everyone while kicking and screaming all the way to path of success and innovation. These engineers are humanity’s hope for a better tomorrow. Their patience, persistence and perseverance shall light up the path of those behind them to follow and inspire those whom they’ve never met to find their own path and create a better future for our world.