I’ve been musing on the concept of codification for a while.
We write code to build software – to establish its internal rules and interactive behavior, and to set its outward appearance for users.
Software development lends itself to the scientific method of hypothesis, experimentation and observation more than that of any human ideals or mindset. After all, they teach computer science in university, not computer philosophy!
There’s a systematic approach for improving development expertise, gathering and analyzing data, and proving or disproving that the software works. Logic and data are codified in software and in our processes around creating software, not ideology.
The human behavior influences of societal norms or religious belief systems seem to have little to do with the quality or performance of the software any given group of developers can churn out.
Ideology as software pre-architecture
There’s something about an organization’s particular ideology for codifying technology that can set it apart from its peers. When team members share beliefs and behaviors, the resulting products can gain a certain consistency in design and utility that ‘just makes sense’ to customers who resonate with the approach.
A company’s founder, or an executive can set the tone for an organization of course – think Steve Jobs or Andy Grove back in the day. But for software development, an ideology is usually more than a cult of personality or a firm hands-gripping-the-wheel steering exercise.
When development teams can perceive and respond to opportunities and challenges as a group, much like flocks of birds or that change direction suddenly, that’s when the magic of a shared ideology happens.
The codification of the group’s encouraged and discouraged behaviors can take many forms, including a predilection for certain technologies or methodologies. In this sense, an ideology establishes an organizational intent that precedes and influences the architecture of any delivered software.
Here’s a few sample dimensions of ideologies that can impact the behavior of teams, and their rate of innovation.
A work methodology is not an ideology
A lot of services companies claim an overarching agile methodology, a ‘customer first’ mentality, or a ‘proven process’ for delivering great work. In a sense, these are branding exercises to give clients confidence that they have a special formula to deliver better software, faster, because they have great processes for attracting and retaining smarter, more interesting people than the next services firm.
But a services methodology, or a special process for organizing work tasks doesn’t translate to the ideologies our vendors cultivate in developing product strategies. It’s why as analysts, we have a hard time evaluating and comparing services offerings, except as they relate directly to product delivery and training, or operationalization of a SaaS solution for customers.
Open source collaboration magic
Open source is not just a category of software, because without a shared collaborative ideology, there’s no sustainable way to keep an open source project alive. At the root of this belief system, open source democratizes access to non-proprietary platforms, thereby leveling the playing field for individuals to build solutions atop them, and societies to benefit from the resulting innovation.
An open source project starts out as a kernel of code in a repository, and a code of conduct for founding the community of current and future contributors.
When attending an open source conference, the ideology of an agreed-upon code of conduct for treating each other with respect rightfully supersedes any actual discussion of code and components. A project that becomes toxic and loses its collaborative ideology gets abandoned, as contributors will take their talents elsewhere to innovate in more interesting projects.
Design-first versus product-first
I covered the quandary of design versus product-led development modalities in my previous Cortex column on design-led versus product-led delivery teams.
Design-led ideologies lean on developer intuition, the healthy competition of ideas, and fast iteration to constantly improve the software customer experience, whereas product-led development focuses on constantly delivering and improving features that meet customer demand.
These modes of thinking are seldom exclusive, and coexist productively within many orgs. Engineering and operations groups for instance may be able to bridge the gap between design and product orientations by crafting shared models that represent their commonalities, giving them a common language to mix the best of both worlds.
Inclusive versus exclusive
An ideology of making ‘software for all’ – which can encompass any combination of users and employees of all skill levels, cultures, and abilities sets a high premium on user experience and accessibility. The world’s most widely accepted products are practically self-explanatory, and are built upon this mindset.
However, many software vendors cater unapologetically to expert practitioners only, or for specialists within a particular industry who must bring deep domain knowledge to bear. There’s great value in the right tool for the job after all.
No-code, low-code and pro-code development tools offer a great illustration of the inclusive vs. exclusive ideology in action.
Software for a higher purpose
It’s easy to be skeptical of companies that say they exist to improve the greater good, ever since Google quietly dropped its own ‘don’t be evil’ mantra more than a decade ago. More recently, the trend of ESG (environmental, social & governance) has been co-opted as the latest form of ‘greenwashing’ by corporate entities seeking to publicize their environmental concerns.
Still, there’s plenty of value in adopting development ideologies that also serve the greater good. If data centers can increase efficient operations and run on renewable energy, and logistics vendors can reduce overall emissions by optimizing truck routes, that’s inherently good for the environment.
A cybersecurity company can have a mission to make the Internet a safer place, or protect customer privacy to motivate employees and customers. An AI company developing healthcare or self-driving cars can set out to save human lives, and the resulting software will be more likely to do so if it matters to the organization.
Centralization or decentralization
Some companies set out on a plan to be ‘one source of truth’ and/or the ‘center of the hub’ for a particular industry or practice. There’s inherent value in giving leaders visibility across applications and organizations, in order to spot strategic trends, resolve emerging issues and make better business decisions.
A centralized product ideology doesn’t necessarily mean market domination – it can also drive an open mindset for partnerships and integration that brings other vendors together, gathering the best sources of information and functionality for customers.
Decentralization at the other end of the software ideology spectrum, seeking to benefit developers with flatter, more open and self-defining organizational hierarchies that encourage remote working, and creativity in helping users maintain ideals through resulting products such as self-control, data privacy and self-sovereign identity.
If decentralized ideologies can escape their often religious affiliation with non-performant blockchains, Web3 hype, and crypto-ponzi schemes, we might see them reenter the general enterprise conversation.
The Intellyx Take
As usual with such an abstract Cortex thought piece, there are many more ideologies bending the arc of technology than I could possibly cover here.
A useful development ideology is not just defined, it is cultivated by a group over time. It is not something the corporate leadership team can dictate artificially.
In today’s fast-paced world of mergers and acquisitions, portfolio companies seldom retain their ideological foundations for long, as the principal collaborators often move on, engaging their efforts and beliefs in the next startup.
Strong ideologies, like strong methodologies and expert practices, are built and reinforced from within. By nature, if ideologies resonate with customers when well-executed as design and codified as code, they can be inheritable by later generations of employees for useful purposes.
Dear reader, if you read this far, I’d love to hear your thoughts. Am I way out on an ideological limb with this Cortex, or do you have some additional commentary to throw into the mix? Comment here or respond to our story on LinkedIn or Twitter.
.jpg){kind=link}