Adaptability
In software development, the lure of the latest fad can be intoxicating. Whether it's an influential thought leader extolling the virtues of their favorite project management methodology, or the notion that enterprise software must be built with the hot language or framework, it's easy to find ourselves swept up in the currents of popular opinion. One might think that to be adaptable, they need to flow with the currents.
However, genuine adaptability lies in discerning the difference between a fad and a paradigm shift, something best done by understanding the history and trajectory of programming methodologies and languages. Take Functional Programming (FP), for example. Long before Object-Oriented Programming (OOP) became the corporate standard, FP was a major force in computer science research. Its decline in corporate use wasn't a result of inadequacy but of business trends and marketing forces. Today, FP is experiencing a resurgence, not as a new fad but as a powerful, alternative paradigm that's regaining the appreciation it once had. Thus, an embrace of FP is not embracing something new, but rather embracing something else. But understanding this requires a historical understanding of the ebb and flow of the programming world.
Such historical understanding allows us to be truly adaptable. It helps us recognize the intrinsic merits of different approaches, rather than just their popularity at any given time. When we know why a particular method gained traction, we're better equipped to adapt or even pioneer new methods tailored to our specific needs. But what is the purpose of adapting? The purpose of adapting is not to stay hip or relevant; it's to gain mastery of one's craft.
Nurturing our adaptability is a call for intellectual independence. Rather than simply accepting what's popular or 'proven' by group think, we can introduce new patterns or languages to our repertoire as is needed to best solve the problems we have. Or maybe even create fundamentally new concepts. Consider state management in software. Before MVU (Elm Architecture) and Redux existed as household patterns[1], there was an acute awareness that mutable state as well as two-way data binding were a source of bugs and complexity in UIs. Both patterns, in their own way, formalized an approach which is not only immutable, but predictable. A certain action always produces the same state, and that state always renders the same view (in a way, immutable, action-based state is the UI equivalent of CQRS and event sourcing on the server side). Thus, when we consider patterns such as these, we should think of them from their historical context. What problems were they solving? Do newer alternatives have the same understanding of the problem, or are they approaching from an altogether different perspective?
We should also keep in mind that considering other industries or communities within our own industry can help us think about problems more objectively. Kanban, for instance, was adapted from manufacturing, and the much loved book "Design Patterns" drew from a similar book about architecture, written decades earlier. For innovators to have the insight to formulate solutions from other industries, it's necessary to escape from the pressure of the fads around us.
Being adaptable isn't just about flexibility; it's about understanding why we do what we do, so that we can do it better. It's about recognizing that we are part of a constantly evolving discipline that requires not just technical skills but also a deep understanding of the underpinnings and historical contexts of our methodologies and tools. So, the next time you're tempted to jump on a trend, take a step back and ask: Why did this become popular, and how does it fit into the broader landscape? Not because you refuse to change, but because you want to change well.
[1] Another recent innovation worth considering that demonstrates the creation of an entirely new pattern to deal with modern challenges is observables. Here's a fascinating article on the creation of 0bservables.