Developers write code, thereby codifying software’s internal rules and outward appearances.
Programming is not a belief system – it’s part of computer science for a reason. There is 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.
The human influences of societal norms or religion should have little to do with the quality or performance of the software a group of developers can churn out.
Ideology precedes architecture
A particular ideology for codifying technology sets an organization apart from its peers. When team members share beliefs and behaviors, the resulting products can gain consistency in design and utility that ‘just makes sense’ to customers who resonate with the approach.
The company’s founder, or an executive can set the tone for an organization of course – think Steve Jobs or Andy Grove. But for software development, an ideology is usually more than a cult of personality.
Development teams with shared ideology can perceive and respond to opportunities and challenges as a group, like flocks of birds that seem to magically change direction.
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 influences the architecture of delivered software.
A services methodology is not an ideology
A lot of services companies tout an overarching Agile or DevOps methodology, a ‘customer first’ mentality, or ‘proven processes’ for delivering great work. A skeptic sees these as branding exercises to give clients confidence and recruit better developers.
As analysts, we have a hard time evaluating and comparing services offerings as they relate to product value, except when they relate directly to product delivery and training, or operationalization of a SaaS solution for customers.
Open source collaboration magic
Open source projects start out as a kernel of code in a repository, and a code of conduct for founding the community of current and future contributors.
Open source believes in a shared collaborative ideology and democratizing access to non-proprietary platforms, thereby leveling the playing field for individuals to build solutions atop them. Societies to benefit from the resulting innovation.
Attending an open source conference, the ideology of an agreed-upon code of conduct for treating each other with respect supersedes any actual discussion of code and components. Projects that lose their collaborative energy become toxic and get abandoned, as contributors take their talents elsewhere.
Design-first versus product-first
I covered the quandary of design versus product-led development modalities in my previous 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 coexist productively within many orgs. Engineering and operations groups 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’ – 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 built upon this mindset.
Conversely, many software vendors cater unapologetically to expert practitioners only, or for industry specialists who bring deep domain knowledge. There’s value in delivering the right tool for the job after all.
No-code, low-code and pro-code development tools offer a spectrum of these ideologies in action.
Coding for global good
Ever since Google quietly dropped its own ‘don’t be evil’ mantra more than a decade ago, I’ve been skeptical of companies that say they exist to improve the greater good. The recent 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, if such goals make data centers increase efficiency and run on renewable energy, and cause logistics vendors to reduce overall emissions by optimizing truck routes, that’s inherently good.
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.
The Intellyx Take
A useful development ideology is not just defined, it is cultivated by a group over time. It is not something that corporate leadership can dictate.
In today’s fast-paced world, merged companies never retain their ideological foundations for long, as principal collaborators move on, engaging their efforts and beliefs in the next startup.
Strong ideologies, like proven methodologies, are built and reinforced from within. If ideologies resonate with customers when codified as code, later teams can inherit them for useful purposes.
