Cutting code and architects

Over the years working on data platforms, I have seen architects writing less and less code, to the point where in more recent times, a seemingly growing number of architects (in data projects) are writing no code at all.

Architects

In simple terms, an architect is referred to as someone whose primary role is the design of a solution and not the development of the solution. Architects translate business requirements, often disparate, into the blueprints for a robust, scalable and cost-effective solution.

The term “cutting code” in this post is merely slang for the practice of using computer programming for activities such as software development, data engineering or data science.

Strategy vs technology

The reality is that there are many facets to architecture in IT and I suspect, the reason why some architects do not write code at all.

The following diagram, sourced from the leanix website (13 Dec 2020), shows 3 types of architects and compares them by strategy and technology focus.

If I had to put it crudely, these days do not expect much or any “coding” from an enterprise architect and conversely, expect a dabble from a data architect. The reason for this could be down to the primary focus of their role and typically what companies ultimately want from them.

For example, in small or growing companies, a data architect may be expected to contribute to the development pipeline and should be able to code (and code well).

So, should architects, in general, be writing code? The short answer is, yes, I think architects should.

The case against architects coding

Lose strategic focus

For larger companies or corporates where an enterprise architect’s wide strategic focus is crucial to their success, writing code may not be required at all.

Writing code could be an unnecessary distraction but personally, I’d still expect some hands on familiarity with writing code to test their assumptions. For example orchestrating data workloads using Tool A is more expensive than Tool B.

Erodes trust

An architect that writes code may feel as though they have the best understanding of the design. This may be partly true but they may not have the best understanding of the implications of their design.

More so, they may be in the weeds to such an extent that they end up making it hard for the development team to do their job effectively. Either by being too slow, too picky or lacking an understanding of the finer details the development work. Removing them from writing code allows them to focus on the design work.

Totally unnecessary

Some companies set the expectation that the architects design and the development team develops the solutions according to the design.

In many cases, the solution architect would not have touched an IDE for many years. The enterprise architect will talk to the team via monthly town halls and the data architect is really the data modeler.

Writing code has been argued to be nothing more than a distraction in these circumstances.

The case for architects coding

Architects need to be able to bridge the gap between technical and non-technical. They’ll need to attend meetings, typically several. They’ll also have to manage stakeholders, provide solution design and guidance for strategy, governance and understand the bigger picture both inside and outside the organisation.

So with all of this, why add to their workload?

Trust

Architects set the technical vision and they need to have the trust of the technical and non-technical folk. Trust to keep the development of the solution in harmony and trust to allay any fears from the non-technical teams that the designs won’t meet their requirements.

Contrast this with an architect having their competence questioned or being labelled as a PowerPoint Architect or Ivory Tower Architect. This is problematic as it erodes trust. As an aside, the label PowerPoint Architect, is a cheeky term to describe architects whose day is consumed in meetings, produce big, up-front designs or documents and leave the sense that they would struggle to put together code in any language.

A lack of trust, in my experience, has emanated from some form of bitterness. Perhaps, some team (e.g. development) is bitter at what they perceive to be a lack of support or knowledge, or even a dereliction of duty by the architect. Maybe the architect comes across as all talk and no substance beyond a reference architecture. Or worse, the designs just couldn’t stand up to scrutiny.

If an architect can write code to put together a basic proof of concept or demonstrate deeper technical insights beyond a high level design, it’ll go some way to building trust in their competence and design for both technical and non-technical teams. Essentially, if they believe you and your designs can walk the walk, it’ll help build trust.

Put another way, if you were looking to get fit and a personal trainer provided an exercise program, would you trust them if they could tell you how to do certain exercises but couldn’t demonstrate the correct form?

Skin in the game

With their primary role typically being more strategic, architects can very quickly lose touch with tools and development practices. Sure, talking about test coverage or a favoured modeling design in a presentation is great but if an architect can demonstrate this by contributing to development then it becomes clear that they understand the implications of their design.

This means that architects can do more than prescribe from a book but actually demonstrate what they say. By being directly affected by their own designs they can better evaluate if their vision is on the right track.

Better bond with development team

If you need your architect to contribute to and guide the development process in your projects, then they clearly need to be writing code.

Even if that’s not the case and the architect will be expected to handle design work only, showing the development team by example, that as an architect you know what they’re going through and what’s going can do wonders for team morale.

It allows the architect to impart some knowledge to the development team, help them understand why a particular design has been chosen and challenge assumptions.

This healthy exchange of ideas gives the architect more credibility with their developers, minimises frustrations with certain design decisions and allows developers to contribute to the design process more collaboratively.

Summary

In short, architects should be able to write code. How much code depends on the expectations of their role but never to the point where they lose the ability to code even the most basic of solutions.