Tech Aside: Architects Suck! Architecture Rocks!

 Introduction

Welcome to another installment of "Tech Aside" series, where I focus on non-technical areas that are a part of Software Developers' world. Were you drawn here by a somewhat provocative title of the article? I've chosen it in small part because it is kinda clickbaity, but for the most part because during 2019 Devoxx Conference there was this great lecture performed by James Birnie, and it had the exact same title. I strongly encourage you to watch it (no actual engineering knowledge required), as it's a great talk and it will give you some context to what I'm about to share here.
 
This article may very well turn out to the most personal entry on this Blog, so if you're not that interested in a bit of my story, thoughts and reflections, feel free to skip it :)

Who was I?

When I've entered the IT Job Market back in 2010, things were very different from what they are today. I came from a small town in Poland and graduated not-so-prestigious college with an Engineering Degree in "Computer Systems and Networks" field. I had no idea what exactly do I want to do for living, I just knew that it had to involve working with computers. I've moved (for personal reasons) to Krakow (one of Poland's biggest cities) and tried my luck there, having just enough money to be able to survive on my own for  about 2 months. I was lucky enough to find a job in one of Krakow's Call Centers - at first as an over-the-phone salesman, jumping to the IT department after a short time. From there my career as a Software Developer started to slowly, but firmly grow. I've experienced all levels - Junior, Regular, Senior, Lead etc. I've changed jobs, developed my technical and soft skills. Things were good and stable. I loved coding and creating new solutions for the business to automate their processes. However there is a point in (I think) every Senior Developer's career when, to move forward, one needs to decide whether to advance to more managerial role (giving up coding almost entirely), or to get kinda stuck in the technical role, doing what one loves to do, but for the cost of not advancing one's career. No choice is good or bad, it all comes down to personal preferences. 

Who am I?

What did I do? I've chosen to stay in the technical path, but I've taken on a position of a "Systems Architect" - a title that I once thought was a peak technical Role every Developer dreams of. Looking around the Software Architecture landscape, now that I kinda am one, things are not as simple as I thought. I don't think there are 2 companies in the world that treat the "Architect" Role in the same way. I even doubt if  there are 2 Architects in the world that have the same understanding of what they're suppose to be doing. Why? Because "Architecture" is so generic and fuzzy term, no one actually knows how to strictly define it.
 
I myself happen to agree with James' definition that "an Architecture is a set of all decisions that are hard to change". That's why I strongly believe that 
  • every Software Product needs to have a well defined Architecture
  • there has to be a person responsible for that Architecture, it won't get created on its own

Having that said, I feel that there are two main issues about being an Architect, that need to be tackled: Level and Responsibilities.

Choosing a Level

There are multiple types of Architects - System, Solution, Enterprise, etc. I feel that they differ in Scope of their work. After all Architecture can be applied to many different levels inside a Business. It can be an Architecture of a single Product, it can be an Architecture of an Infrastructure (Cloud vs Local, appliance of Containers, choosing messaging technologies etc), an Architecture of a Business Line (that has multiple interconnected Products, that together should fulfill business goals). Furthermore I'm certain that there are different cross-cuts of all of those fields, depending on the actual Company.

As I've said, I want to stay close to the code (because that's what I love and that's what's been propelling my entire career up to this point), so my Level of choice is a Product Architect. OK, but what does it exactly mean?

Defining Responsibilities

In the Devoxx talk James takes on different anti-patterns of being an Architect:

  • "Architectologist"
    • Someone that works with lots of legacy systems and doesn't promote practices that would lead to Business and Technology growth, but instead, consciously or not, promotes creation of knowledge silos, deepening the technological hole that the Company is in.
  • "Technology Police"
    • Someone that obsesses about technology standardization at all costs, making charts and spreadsheets of stuff that's allowed and stuff that's not allowed. Who doesn't promote the 'use the right tool for the job' attitude, forcing everyone to use the same tools for every problem.
  • "Framework Builder"
    • Someone that, in order to make sure no one makes bad design choices, builds an actual Framework that all the Dev Team members have to use. That forces his visions, ways and ideas onto the Team without letting them make any meaningful decisions, thus squandering the creativity potential of the Team.
  • "Librarian"
    • Someone that believes that Software Architecture is actually all about the documentation. That obsesses about documenting every single technical detail and, even worse, tends to come up with upfront detailed technical designs (in a form of a documentation) of entire Epics and/or Stories.

Out of those four, I was, for a pretty long time, the "Framework Builder". I've created some pretty complex and "sophisticated" Frameworks that in general, worked good. However there were 2 problems with them:

  • they imposed too many patterns and practices for the developers to feel truly creative and to feel the freedom that we all love, when tackling new business problems.
  • they aged badly, because they were revolving around either a concrete technology (jQuery, raw PHP (way, waay back in the day), GWT-based Vaadin, etc) or a concrete methodology (Event Sourcing, CQRS, DDD, etc)

I felt that I had to have total control over what everyone is doing and how are they doing it. I needed to make sure that no one makes a bad design decision that will cost us in the long run. And you know what? To some extent, I still feel and need all of those things, because I bear the sole responsibility for the Products I'm working on. Management doesn't want a shared, distributed responsibility, they want a single person to blame if something happens. And that's OK. We don't live in a perfect world where everyone can communicate with everyone else with utmost empathetic and understanding attitude. Every company has a chain of responsibilities (chain of command) and I am a block between the Management and the Dev Team. I shield the Team from any backlash and pressure, giving them space to actually work and create. To be able to do that, I need to employ some control measures, that will ensure high technical and architectural quality of the Product I'm responsible for. The question is, how to do that without becoming the dreaded "Framework Builder" and/or any of the other anti-patterns?

My Architecture

There are a couple of key points to me being and Architect:

  • I've realized that building Frameworks makes no sense. We need to utilize the Frameworks that are already there and that are battle-tested and production-ready. Instead of building new ones, lets use the ones that are available, making sure that we don't misuse them and/or turn them into anti-patterns.
  • I came to a conclusion that, instead of hard-coding the Architecture, I need to come up with a generic set of well-established principles that won't feel too restrictive, but will ensure that all the developers in the Team produce code that the others may easily navigate, understand and extend. Focus on modularization, proper packaging, visibility and naming conventions. Choose the right Persistence/Messaging tool sets. Promote good testing practices, like BDD. Make sure that automated tests are on the right level and of the right quality. Be an enabler for the Team, not a Policeman. Let everyone do their things the way they want, as long as they adhere to couple of high-level general rules and conventions.
  • I always was and will be a practitioner. I don't believe that you can come up with something useful and practical, if you haven't used it yourself. That's why I always will strive to combine my Role as an Architect with a role of the Lead Developer. One of the most important things when establishing rules and conventions is Developer Experience (DX for short). Ideas can look good on paper, but you won't know if they work, until you'll actually try to apply them in a real-life scenario. In that sense I'd rather be called a Lead Developer responsible for the Architecture, than an actual Architect in the traditional, non-coding meaning.
  • The Product has to not only look nice and slick on Demo sessions, but has to be ready for real-life production usage. That's why all of my decisions, designs and principles always revolve around performance. I tend to tackle the most performance-critical parts of the Product myself or have a very close oversight on them, performing very thorough Code Reviews of all such components and creating additional performance verification, in a form of JMH test suites.

Conclusion

I don't know if I'll ever want to be the kind of Architect that only goes to the meetings, works with whiteboards and tools like JIRA and/or Confluence. The kind that only draws the Architecture in little boxes that look nice to the Management. Don't misunderstand me, I don't think lesser about such Roles, they are simply not what I want to do. I love to code and I love to bring real, concrete value to my Customers. Being an Coding Architect I am right now, I can double up on that, because I can treat both the Business Stakeholders and my Development Team as my Clients and deliver them the best possible experience. I truly believe that my current set of Architectural Principles is generic enough to allow for the much needed creative freedom and can even be ported to other JVM and non-JVM platforms. I've battle-tested and tailored the Agile approach to achieve great results and to deliver features on time, on scope and on budget. I don't know what the future holds for me and I most definitely am not done learning. It can be that 10 years from now I will read this article and laugh at my own naivety and/or lack of knowledge. For now, I'm happy with the things being as they are.

Thank you for reading!

Comments