An interesting paradox struck me just recently. Having written nearly 2,750 articles here on this blog, I can probably lay claim to being a writer. Having done well over 50 OSS-related projects since the first one in 2000, I can probably also claim to be an OSS architect and consultant (although impostor syndrome does make that claim feel less warranted).
The paradox lies in the distinct personality differences of those two roles – author and architect.
An OSS architect’s (or OSS consultant’s or OSS implementer’s) role demands a high level of accuracy, expertise and confidence. Whether designing new systems or integrating existing ones, architects must be confident and precise in their decisions, as must consultants in their recommendations. Errors can lead to inefficiencies, system outages, customer dissatisfaction, or revenue loss, so there is little room for error. This requires a strong sense of ego—the belief in one’s ability to create and execute complex designs successfully.
Architects must make decisions with certainty, often defending their choices to clients, sponsors, stakeholders and development teams. And yet, there is never a single, perfectly right answer to any OSS problem. There is no black and white, only many shades of grey. There are generally countless possible ways of building and configuring an OSS solution or solving an OSS-related problem.
Many a time and cost blow-out in an OSS project (none of my projects of course 😉 ) can be attributed to analysis paralysis and/or architects butting heads about which option is the most right (theirs, naturally – Did anyone say OSS-religious wars??)
In contrast, writing about OSS involves speculation, humility, and the willingness to embrace diverse perspectives. Moreover, it involves putting ideas out there for ridicule (for which many of my ideas are certainly supremely worthy!!). This is the antithesis of building a sense of ego!
Writing about OSS is an exploration of ideas, technologies, alternate approaches and future possibilities. It requires you to speculate, question and embrace uncertainty. More importantly, it actively seeks out the opinions of others. In fact, that’s one of the most important, yet unexpected, parts about writing – it’s the feedback. Feedback provides different perspectives, different approaches, different ways of getting things done. It might take a 50% complete idea to a 90% idea. I love getting feedback (although it can be a bit demoralising to find out just how bad my ideas are 😀 ). Breakthroughs or lateral ideas often come from vague notions, hunches, or loosely-held insights that evolve through discussions with, and the genius of, others.
Unlike architecture, where definitive answers are often required, writing allows for multiple hypotheses, interpretations and outcomes. It encourages discussion around the grey. This demands a level of humility that contrasts sharply with the architect’s “certainty.”
This dichotomy is so stark that I wonder whether it’s indicative of a split personality (please don’t answer that!! 😉 )
Despite this paradox, it’s blatantly apparent to me that writing makes me a better architect / consultant / implementer in many ways (eg greater open-mindedness, reduced ego and more humility, willingness to seek the insights of others, actively seeking ideas that extend beyond the immediate projects I’m working on, etc). And being an architect / consultant / implementer has made me a better writer because it allows me to bring stories from the coal-face (the current approaches, pain-points, empathy for others doing the role, etc). Still far from perfect at either role, but definitely better.
If you’ve ever wondered whether you should write a blog and share it with the world, I’d suggest to start writing and publishing immediately. There have also been so many other benefits of writing that I never expected, but I’ll save that loooooonnnnggg list for another day. I have no doubt that writing and publishing will help your career in OSS too.
If you’d like to chat about your writing journey, feel free to drop me a note.
Have you ever had an OSS or BSS project that’s impacted by poor data quality? The problem of data integrity gets raised on almost every
“One of my favorite things about designing software is designing the defaults. The defaults define the experience for everyone out of the box. And, therefore,
Have you ever been tasked with mapping out the processes for the telco you work for? Either as a way of documenting current state, or
In the last week alone, I’ve had two potent reminders that the world of OSS is simply (pun intended) too complex. This manifests in many
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
