Writing code is a creative process that involves using brackets and other symbols to encapsulate logical instructions, creating a framework that helps prevent errors. It’s like placing your thoughts inside brackets, and to excel, precision is key.
Software engineering, a broader concept than just writing code, encompasses the art of not only crafting individual pieces of code but also ingeniously connecting them to produce a cohesive whole. It’s the strategic orchestration of code components.
While coding tends to be rigid, software engineering strives to be flexible.
This flexibility is crucial because software engineering acts as the intermediary layer between code and the dynamic real world.
In the real world, adaptability is key, and flexible software is more likely to align with the ever-changing demands, unlike rigid counterparts that may quickly become outdated.
Foreshadowing
In the professional landscape, one often encounters the intriguing phenomenon of what we affectionately call the “inflexibility monsters” among software engineers.
Imagine this: some individuals become so snug with a specific development framework or stack that it’s akin to discovering their preferred pair of pajamas. Additionally, there are those who, in their pursuit of flawless code, inadvertently establish an environment devoid of levity for our newer developers, treating any hint of suboptimal code as if it were a mythical, three-headed coding gremlin.
And then, soft skills – delightful as they are. Yet, when someone venerates organizing tools like sacred scrolls, transforming each task into an epic saga with hundreds of sub-tasks, it naturally prompts an arched eyebrow. It’s akin to converting a coding adventure into a bureaucratic odyssey.
These idiosyncrasies, born from a lack of flexibility, can give our software the feel of being tailored for an exclusive niche club rather than mingling on the dance floor at the software success party.
“Stranger Things” : A Spooky Retro Tale
Many enthusiasts in OS development often wonder why “Plan9” from Bell Labs (not “Plan 9 from Outer Space“, the movie) met its demise despite its promising features.
The successor of Unix, Plan9 and its later iteration, Inferno, were conceived as evolutionary steps – some might label Plan9 as “Unix 2.0” and Inferno as “Unix 3.0”. Plan9, departing from Unix conventions, presented a revolutionary concept by treating “everything as a file“. In contrast to Unix and Linux, where this idea remains somewhat aspirational, Plan9 took it quite literally.
For instance , even the windowing system, was considered a file. This approach allowed someone using “Rio” Plan9’s second window manager following its first “8½” window manager, with the correct permissions, to observe and manage a screen from the network by simply mounting the folder containing the windowing system. This process eliminated the need for tools like the “X forwarding” in the Linux world… (or modern remote desktop software on Windows)
In Plan9’s “everything is a file” philosophy, many tasks that typically demand dedicated tools in the Unix (thus Linux) realm were seamlessly integrated by design logic.
However, this innovation came at the cost of flexibility. While Unix (thus Linux), often requires specialized tools for various functions, Plan9 opted for a one-size-fits-all approach. In Unix (thus Linux), tools are tailored for specific tasks, each with its unique functionality. Plan9, on the other hand, implemented a default logic for everything, expecting the entire world to conform to its methodology rather than adapting to diverse scenarios. Despite its superiority in certain aspects, this lack of flexibility proved to be a stumbling block. The world, enamored with the adaptable Unix (thus Linux) and its… myriad tools, never fully embraced the less-flexible, albeit innovative, Plan9.
The god that failed
Among “inflexibility monsters,” some of my favorite engineers of all time might find a place !
Bjerne Stroudurp designed C++ language with the intent of “making it harder to shoot your feet, but when you do, you blow the whole feet out,” prioritizing foot safety over fun.
Surprisingly, the success of his language wasn’t solely due to this cautious approach but rather the flexibility it offered by being simpler than C. Many people gravitate towards C++ not necessarily to avoid foot-shooting incidents, as in the metaphor, but simply because, at the end of the day, it presents a more straightforward version of C.
In an recent interview, Bjerne, himself, said as an advice “don’t overspecialize… don’t be so sure you know the future… be flexible…“.
On the other hand, Brendan Eich, the brilliant mind behind JavaScript, concocted a unique blend of languages, drawing inspiration from “Self” and “Java” to create a linguistic Frankenstein! Not only that, it’s known that he created the language in just 10 days.
Surprisingly, this language has garnered a larger community and, consequently, greater capabilities than the sophisticated Python, which adheres to the mantra of “there should be only one way”. The magic lies in JavaScript’s chaotic nature, placing a premium on flexibility. This unpredictability has propelled it to become the world’s most cherished language.
Linus Torvalds, creator of Linux kernel, could easily be characterized as the god of inflexibility from his stringent comments on contributors’ commits – especially during its early days. Ironically, he established his foundation on a highly flexible system: Unix.
Balancing Inflexibility and Flexibility for Software Alchemy
One might easily deduce that lurking behind every inflexible system or developer we admire, there is a flexible aspect that truly struck the gold. This insight stems from the recognition that crafting software is inherently inflexible, demanding a touch of adaptability.
Consider the concept of elasticity and flexibility in materials, as explained by physics. In the physical world, structures like bridges are designed to be flexible to withstand external forces such as wind, temperature changes, and traffic loads. When a bridge is too rigid, it becomes more susceptible to cracking or failure under stress.
Similarly, think of a ball and an egg. A ball, being flexible, can absorb impact and deformation without cracking easily. On the other hand, an egg, although seemingly fragile, has a curved structure that distributes forces evenly, making it more resilient to pressure compared to a rigid object.
Now, draw an analogy to software engineering. In a flexible system, developers will be more productive and users will find their way inside your system.
Just as a flexible bridge can adapt to changing conditions and a flexible ball can absorb shocks, flexible software and mindsets can adapt to evolving requirements and changes without breaking. In the software field, embracing flexibility post-coding allows the software to gracefully handle unforeseen circumstances and modifications, enhancing its robustness and sustainability.
Therefore, dear software engineer, the plea is clear: be inflexible while writing code and flexible when you finally lift your hands off the keyboard. After all, the real magic often unfolds in the realm of flexibility post-coding.