There’s a common misconception that’s permeated our profession: Architects don’t need to write code to do their jobs.

Now, this may seem like a harmless approach. After all, writing code is what developers do. And architects should be busy with more important tasks.

However, keeping architects from writing code can limit the potential of your development teams. It can also result in an architectural mess when requirements and business needs change.

So today let’s look at why giving your software architect time to write code is a good thing. But first, we’ll start off by looking at what life is like as an architect.

So What Do Architects Do?

This is a popular question. Many developers, product managers, and even some architects aren’t sure what architects do. 

But that’s pretty vague. Let’s dive a little deeper.

Expectations

Ideally, an architect creates a technical vision that results in a maintainable and reliable product. She aligns disparate teams that come together to build an interdependent software ecosystem. Additionally, she shares high-level integration decisions that communicate how apps and components should work together. Beyond that, she also reviews and prescribes tools and frameworks for common software problems. And she ties all of this together by communicating the goal and vision for the final product to stakeholders and leadership.

So that all sounds great. And you may be wondering why I’m trying to put more on this busy architect’s plate. To understand that, let’s consider how this picture I just painted correlates with real life.

Reality

What reality looks like varies from company to company. In fact, some companies do let their architects write code while fulfilling all their other duties. But we’re not here to talk about those companies. What I’d like to focus on is what the non-coding architect does at organizations I’ve worked with.

First, the non-coding architect spends much of her time in meetings. She’ll also prep for those meetings with lots of PowerPoint and Visio. In fact, that’s where the term “PowerPoint architect” comes from. After that, she may write design documents, molding her vision of the software design into a 50-page book to be shared with developers. (Alas, this big up-front design is out of date the day it’s approved-sometimes earlier.) Later, she’ll review other design documents, sign off on design choices, and repeat all of that until she forgets what an IDE even looks like.

What Happens When Architects Don’t Code?

Without seeing the day-to-day development process for a product, one might assume all is well. The timeline still looks good. Functionality is being added. We’re moving toward our goal.

But what else is going on?

Architects Lose Touch with Tools

When architects don’t code, there are things they lose touch with.

For one, the architect doesn’t always see when libraries and tools fail to solve problems. There may be tools an architect prescribes that worked OK in textbook scenarios, but that often cause a lot of pain for more complex yet typical use cases. Or the reverse of that happens, where he recommends a tool that’s ideal for complicated scenarios but is overkill for the simple day-to-day problems that a developer runs into.

Unless the architect uses his own recommendations, he could be completely unaware of the repercussions of his choices.

Designs Don’t Fit Changing Requirements

When considering software development, we can’t assume a static world. The architecture designed up front cannot consider all the variables and edge cases. There are nuances that won’t be found until well into the writing of the software.

In summary, architecture and design decisions often require change.

Now you may say that this isn’t a problem. The architect can just go back and redesign the system. However, that’s not what typically happens. Instead, the developers notice something’s not quite right. That things are becoming difficult. And they can do several things. They can bring it up with the architect, who’s no longer close enough to fully grasp the situation. They can redesign the system themselves. Or they can hack that square peg into the round hole as best they can and move on.

Had the architect been closer to the team and writing code, he could have seen the changes coming and modified the design in real time. He could also have done minimal design up front and worked with the team to evolve the architecture of the system over time.

Developers Become Frustrated

The development team also suffers in a few different ways from both having all the design handed down and not having the architect embedded with them. First, as I mentioned above, things change. And not having the architect close by to talk through the changes causes delays.

Second, many developers don’t like a paint-by-numbers approach to programming. They want to be able to create designs and make decisions. If things are spelled out too finely, it takes away from the creative process.

Finally, when the development team starts noticing that things don’t line up as they did on the architectural diagrams, they blame the plan. And they feel like the architect just doesn’t quite get it. Whether real or imaginary, impediments to producing working software can be seen as the architect’s fault.

The Solution

As long as we watch out for a few pitfalls, which we’ll get into later, what can we expect to gain from having our architects write code?

Respect for Architecture

I’ve seen a few examples of developers losing respect for architects. After all, architects don’t code. They don’t know what it’s like trying to balance readability, design, and maintainability.

So when architects do code, they show the development team that they’ve been there. They know what’s going on. And they’re willing to roll up their sleeves and get dirty when needed.

In addition, architects can also share design insights more frequently. Oftentimes, developers don’t see the need for architectural patterns because they haven’t seen good ones that made life easier. Architects can help with that by putting together skeletons of the design that show the potential. Or they can help the team refactor messy parts of the code into something elegant.

Better Understanding of Design

When architects write code, they have the opportunity to communicate design ideas and principles to developers with greater impact. It’s one thing to see the adapter pattern drawn on a whiteboard and quite another to see one living in your IDE.

Additionally, architects should encourage developers to think about design themselves. As a mentor, you can teach developers to deal with unexpected changes and find the patterns and design that will solve the problem. You should discuss the pros and cons of solutions openly and allow for questions and discussion, and always make the design collaborative.

Another option involves prototypes. If architects prototype some of their architecture design, they’ll see at least partly how it works in real life and how it provides something the team can build from.

Real-Time Design Updates

Architects who code can evaluate alternatives in real time. When an over-architected solution is going to take too much time, an architect can provide insight on which open-sourced or purchased library the team could use instead.

Keeping an architect with the team ensures the architecture can pivot to fulfill changing needs. Additionally, there’s less of a push to over-architect everything up front.

And if the architect is in the code at least weekly, she’ll be able to see if the code strays from the vision before it’s too late to right the course. Also, the architect will have a better handle on what technical debt is being created. And she’ll be able to help guide the team on when to add to technical debt and when not to.

Architectural Ownership of the Final Product

When an architect writes code on the front lines, he suddenly has more ownership of the product. There’s greater visibility into what his solution costs the business. And if he’s made to code his solution, he’ll soon realize what design decisions are critical and what parts he can do without.

For example, architects often have a need to plan for every possible scenario that might happen. But at the start of a project, it’s often hard to know which problems are real and which are imagined. Or at least which ones are unlikely. There’s no need to create a giant maze of redundancy and scale if we only end up having 100 customers. Let’s focus on delivering value first.

Potential Problems

Proponents of the no-code club have a few points to make about why architects shouldn’t write code:

• They’ll lose sight of long-term vision or bigger issues.
• Understanding the application doesn’t require knowledge of the minutiae.
• Writing code discourages architects from delegating.

And I get it. You want to make sure your architect does what he was hired to do-make long-term and high-level decisions. But, we’re not asking architects to spend all their time writing code. Instead, we’re simply asking them to spend at least some of their time making their application designs come to life.

As for the point about poor delegation, I have definitely seen this in the wild. You’ll often encounter an architect who’s more than willing to write code but who’s not willing to hand anything but the most basic parts to other developers. This architect needs to be able to trust the development team to write the code. And the developers should be able to take on more and more complex work over time.

Benefits for Everyone

Ultimately, having software architects write code benefits the whole team and the final product. It also encourages the sharing of design ideas and fast feedback. And it helps everyone on the team grow.

So let your architects code. Let your developers design. Work as a team to provide the best solution for the problem.

更多精彩，請點選