Should architects code?

Originally published on May 18, 2021. Content Re-Edited

Yes.

It is straightforward to say yes and end this post abruptly, but I'd be doing a disservice to the industry. To understand why, it's essential to understand the career paths and organization of the general aspects of software teams.

Generally speaking, I think that there are several primary career paths one can take in the wild world of software development: Technical and non-technical individual contributors Technical and non-technical people leaders Other.

For this discussion, I'd like to focus on technical staff. I want to maintain that product, business, UI/UX, and non-technical staff contributions are critical for organizations' success. However, the initial focus of this article is to double-click on a polarizing question within software value streams: should architects code?

Yes, and.

Individual contributions

When most people think of software, they think of the stereotypical programmer. We think of someone sitting in front of a computer making magic with their fingers and brains.

The reality is that this is an endeavor of depth. Software developers specialize in a specific tech stack or business domain. For technologists to grow, it is essential to drill through the bedrock of computational knowledge, achieving an ever-deepening command of the tech stack, algorithms, data structures, the constraints and characteristics of their business domain, and still an open mind towards adjacent concepts.

A junior Java developer might evolve into a senior developer of JVM-based languages with expertise in Spring, Hibernate and an event-driven architecture. Debugging chops evolve from "insert print statements" to "stepping through a call stack."

Fortunately, many tech stacks share common attributes of computation. An algorithm or data structure differs slightly from stack to stack based on the semantics and features of that stack. Stack-specific implementations might abstract understanding differently, shaping what aspects of the governing dynamics we naturally retain and those that slip away into obfuscated oblivion.

Growing a career in development has often been stifled by damaging organizational assumptions that to move forward in your career; you must move into management.

I have worked with many brilliant developers who have earned a leadership stake in a team or organization. They stand influential, thoughtful, and productive. However, people management is not necessarily among their more significant assets. Only some have this skill set. Not everyone wants it, either.

Facebook is a fantastic example of an organization that values these high performers by creating a career track that breaks through the drop-tile ceiling into higher-visibility positions without being forced into formal people leadership positions.

Historically, these positions didn't exist in traditional organizations, forcing developers to decide between staying in an undervalued position or moving to a management role they likely didn't want and were probably not qualified for. The latter leads to feelings of despondency and potentially a web of depression and frustration. No one wants to feel set up to fail.

People management

It makes sense that most developers have to report to someone. Even extremely flat organizations have some concept of accountability reporting.

We've discussed how some developers lack the skill or desire for management. On the other hand, some are born for it.

Many developers thrive in mentorship, coaching, and acting as a multiplying influence on their peers. These traits are a good start. They are some of the fundamental characteristics of leadership. However, leaders can do so with or without authority. As mentioned in the previous section, many individual contributors can practice peer leadership.

In most cases, peer leadership is more likely to be practiced from a position of credibility rather than authority. Principals, fellows, staff engineers, distinguished engineers, and architects all come with a degree of experience that, when delivered with well-honed leadership skills, fosters organizational learning and unity. The relationships resulting from this team-building category are much closer to kinship than hierarchical.

Management requires more. It requires some understanding of the business appropriate to its level within the organization. It requires a knowledge of how to unblock problems and the ability to build strong professional relationships external to their team across an organization to advocate for the team's behalf. It requires the ability to help keep team members focused on their specific tasks.

I referred to software development as a depth activity. People management is about serving the needs of a collection of individuals. It is an enablement activity. It's unnecessary to define further because a good manager recognizes what needs to be enabled and helps ensure it happens.

In many cases, the skills that require honing aren't technical. They could be a case of time management or interpersonal skills and communication. A good manager understands these skill sets and can coach them to help drive the needs of the business. However, it is a great manager who has such mastery over these skills that they may influence change to drive the needs of the business and grow the careers of those they are coaching.

It is worth noting that while many developers come from hands-on backgrounds, many organizations hire software leadership positions from project management backgrounds. This practice opens up complexities such as project management vs. technical project management and organizational details that impact hiring, operational model, and the prioritization of leadership skills.

Neither one nor the other is better; however, they are different, so we must adequately structure the organization to complement the characteristics of each pattern.

What do architects do?

We've covered individual contributions regarding development and the management function that keeps the contributors focused and aimed toward the organization's needs.

So what does an architect do?

I have no idea what you do. - My Wife

Most people don't know what software architects do. When asked to define it, responses lean towards the general definition of what an architect does. We build things.

Sure, this is a fair high-level description, but the result will be generic if someone attempts to perform a software architect's work generically. A generic solution might be a frisbee if given the requirements to create a wheel.

There are books written at a fairly brisk rate (as technical publications go) describing the job function of software architects, so please forgive any license I take to whittle this down for brevity.

Architects receive business requirements and participate in clarification and refinement procedures that help translate the language of the business domain to technological concepts. The more we know about technology, the more options we have to solve the problem space summarized by the requirements.

This definition is still massive in scope.

The industry collectively distills software development into a tactical, depth-first activity. Leadership, especially executive, is viewed as a strategic, breadth-first endeavor.

Architecture, software or otherwise, is a conduit. Architecture is a translation that exists entirely to facilitate the balance of competing frictions or tradeoffs and remediate their side effects. Syvatoslav Kotusev describes organizations at a high level in terms of three different sets of opposing forces: internal vs. external, technical vs. business, and strategic vs. tactical.

These opposing forces exist in an organization's daunting array of combinations and permutations, let alone across numerous organizations. Many factors influence these forces, such as domain, culture, organization size, and political or economic climate.

I used to think of architecture as a breadth-driven activity. I'm afraid that's not right. Even with good intentions, this leads to an ivory tower because it exists in a state of natural friction with the tactical participants of a technology value stream.

Consider the detailed activities of an architect. We negotiate, we differentiate, and we compare. We can describe almost every action in an ideal ecosystem with a verb that places us in the middle of the frictions I mentioned above.

Navigating these obstacles, we devise the closest, not perfect, solution. We strive for reusability, but sometimes even the slightest adjustment of the parameters to the problem can require a different answer.

Speaking of answers, we still need to answer my initial question: should architects code?

Maybe.

Thus far, I've positioned the architect as a mediator, referee, marriage counselor, or arbitrator of various forms of friction. Based on that description and the fact that one of those forms of conflict is navigating strategies and tactical execution, some architects should at least understand how to read code.

However, I deliberately indexed on the skillset of moderation or facilitation. I did this because some organizations are so large that multiple layers of architecture practitioners may exist. Not all of those architects will work adjacent to software developers—the frictions they make and the decisions they nurture may be elsewhere within the organization.

We need to ask the right question. Should architects code?. Should software architects code?

Now we are getting somewhere.

Enterprise Architects, Business Architects, and other architects not adjacent to software delivery teams may not need to code. It will depend on the organization's size and the role's positioning.

Furnishing effective architectures means that architects must be able to justify choosing solutions A over B, C, and D. We have to know that the alternatives exist and understand the components of each. We have to understand how each solution resolves the problems we face. Solutioning involves evaluating the presence or lack of benefits and weighing them against the business needs.

So what does all of this have to do with coding?

Don't get dumber

Software architectures are more than pretty drawings to be filed away in cabinets or stored on wikis. They want to fly. They want to exist in production. At some point, architecture has to become tangible (as much as software can be.)

Architects who stop coding altogether become code-dumb. (A former employer referred to this as 'post-technical'). They no longer remember implementation details. They forget the pain and entropy associated with maintaining and curating the systems they create. This negatively affects the designs because decisions might become too high-level, impractical, or unattainable.

As an architect steps away from the implementation, they are also stepping away from the ubiquitous language and kinship of software development that connects architecture to its performance.

Should a software architect code to remain credible?

Yes. Technical credibility fosters relationships and mentorship with developers and tech leads. It builds confidence within the delivery team and builds trust from business leaders.

It doesn't necessarily mean they should write the same code as the development teams. Coding for credibility could be open-source contributions or personal projects. Remember that the credibility you can establish will depend on how much relevance there is to the code you work with and the code you write on your own.

Personal coding raises some questions; before I pose them, I want to mention a sidenote that's important to consider. Sometimes, there is value in deliberately working on a side project that differs from what you spend your time doing for a paycheck. Sometimes porting a design to a different cloud platform or technical solution provides a new perspective. Write a service in a different language.

Returning to the questions I mentioned, if we're going to code for credibility, and there is value in coding in a proximal domain and language to what you do for work, why not just write code at work?

Should software architects write production code?

Asking this question is more sensitive than the previous questions. It can quickly become a catch-22. We've already established the value of credibility with software teams; however, there is such a concept as too much of a good thing. Architects, even those working closely with software teams, will have much demand for their time. Many organizations have fallen victim to a pattern where architects own cards or tasks similar to the software development teams. Unfortunately, the need for their time delays their work and impedes a team's progress.

Finding a balanced, thoughtful answer to this question is vital to the function of an architecture practice.

Finding ways to have architects push code can be invaluable to a business. It's also possible to push code into production without it being product features. Even if we find a way for architects to own cards with no dependencies, we're doing a disservice to the team because the kind of feature work we put on most cards is surgical. It is too precise to complement the focus of the architect's role.

Tests, fitness functions, technical debt, automation, tooling, and optimizations are all excellent ways for architects to push lines of code that provide multipliers to the teams and value to the business.

Should architects code?

I'd be doing a disservice to my peers if I said yes or no. The only absolute in architecture is that everything is a tradeoff. We have to look hard enough to find it.

I'll turn this question back on the architects out there reading this. Should you code?