5 Reasons Architect and Developers Argue
Editorial Note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, check out NDepend and download a trial.
There’s a cute term for a blog post or article that advertises, in its title, a number of points of interest. For example, “9 Tips for Getting out of Debt,” as a title would quality. This is called a “listicle,” which is a conjoining of list and article into one word (though, for me, this somehow manages to evoke the vague image of someone licking an icicle).
This template is not normally my style, but I thought it might be fun to try it on and see how it goes. The topic about which I’d like to talk today is the various vectors for architect-developer tension and this seems, somehow, uniquely suited to the listicle format.
Where the developer role is pretty standard, the architect role is often vague in its definition and can vary widely from organization to organization. In some shops, the architect is just the longest tenured developer, whereas in others the architect is a specialized role that generates mountains of UML diagrams.
The ambiguity and variance, combined with the fact that architect is nominally ‘above’ developers, creates a breeding ground for interpersonal friction. While not always present, this is a common theme in the industry. So, I’d like to examine 5 reasons for strife between developers and architects.
1. The Miscast Architect
While there is considerable variance among firms in the industry about what the software architect does, exactly, there is little deviation from the idea that the architect is technically accomplished. Almost invariably, the expectation is that the architect started as a developer and excelled in this capacity.
In situations where this isn’t true, sparks tend to fly. I’ve seen firms ‘promote’ mediocre developers with lots of domain knowledge into this role, the way one might expect to see project managers selected from among the developer ranks. The idea here is “we don’t want this person coding, but we don’t to lose his knowledge of the business.” Whereas this can work with analyst and PM roles, it’s a recipe for disaster with the architect role.
The same reasoning holds for new hires or transfers. Taking non-technical people and calling them architect is a great way to raise the hackles of developers and build resentment.
Quick Organizational Solution: Find a different job title for people in this role.
2. The Cowboy Coder
Being an architect is tough. It usually requires wrangling a bevvy of competing concerns: pleasing the business, keeping a finger on the pulse of new trends, ensuring the application portfolio is maintainable, reviewing design and code with developers, etc. For all of these things to go well simultaneously, effective and valuable communication is a must.
The cowboy coder is anathema to this operating mode. This is the developer who, following a team agreement and architect blessing to use SQL Server for the application database, builds his own disparate feature set that uses a file or in-memory database instead, because “it’s better.” The architect is generally looking at a broader range of considerations that might include team expertise, licensing costs, future interoperation, external applications, etc. Developers springing surprises like this on the architect is a surefire way to send her into orbit.
Quick Organizational Solution: Reign in the cowboy coder, with reasoning or with reassignment.
3. The Ivory Tower Architect
This is a classic figure in the world of software development. The ivory tower architect is a developer who was promoted long ago and has completely lost touch with modern coding practice. This guy probably hasn’t written a line of code in 5 years or more and, instead, dreams up elaborate (and often dated) patterns and grand plans.
He sends these over to the development team, and the response there is typically mostly to ignore them. This isn’t malice on the part of the developers, but rather a practical operating decision in response to being asked to do things that are outdated and make no sense. More often than not, the ivory tower architect won’t know the difference, but every now and then it will come to the surface that the development team is paying only lip service to his designs. Cue a serious argument.
Quick Organizational Solution: Make your architects write some code, if only occasional prototyping.
4. The Pusher (Complainer)
For architects, another headache-inducing developer archetype is what I’ll call the “pusher.” This is a developer that really likes a programming language, framework, tech stack, tool, or pattern.
You might recognize the pusher as someone who inexplicably takes a job in a Java shop and, from day one, complains about how awful Java is and how all of these problems wouldn’t exist if the team would switch to Ruby. The pusher will have no business case or feasible migration strategy in mind – just an endless series of complaints about everyone is doing everything wrong and stupidly.
Quick Organizational Solution: Tell pusher to put together a credible migration/implementation plan, backed with a business case, or else to shut up.
5. Lack of Relationship Clarity
As I mentioned earlier in the post, there’s a lot of ambiguity around the architect’s role from organization to organization. This, however, isn’t limited to the role’s duties – it also encompasses the role’s authority. Simply put, in a lot of shops, the developers will wonder to themselves about the architect, “do I have to listen to her – is she like, my boss, or is she just kind of more senior here?”
This lack of clarity tends to lead to a lot of tension in and of itself. No one likes listening to a boss tell them to do things that they think are dumb. But it’s actually worse when you kinda-sorta think that person is like your boss, but you aren’t really sure. And, on the flip side, if you’re not sure that people have to listen to you, it can contribute to a more shrill and didactic tone. None of this is good for the relationship.
Quick Organizational Solution: Make the pecking order, roles, and responsibilities crystal clear to all.
Anywhere you have more than one human working, you’ll have the potential for disagreements, and anywhere you have more than two of them, you’ll have politics. Disagreements and tension are inevitable, but you can certainly limit them and channel them into productive outlets.
The architect-developer relationship is one that creates a natural fault line for potential disagreement. But it’s also one with a lot of potential for mentoring, effective collaboration and growth. If you identify and mitigate the ambiguities and behaviors that threaten the relationship, realizing these benefits becomes a lot more likely. If you’re going to have developers and you’re going to have architects, it’s in everyone’s best interest for them to work well together.
Great post. you nailed it. I have seen number 1,3 and 5. that title is so different in every company. I have seen architects that last time they wrote code was in the .net 1 version. they just got promoted and now after 10 years, the company is rewriting the code in the newest principals, and that guy, who wrote code in 2003, is now the architect. in many places I have seen a mix of both 1 and 5, and even 1+3+5. amazing. In most places the architects are just promoted senior developers (or dev leads) that they had… Read more »
I think maybe the upshot is that there’s no shortage of ways for people working together on software to irritate each other 🙂
It’s funny. I’ve held the title of architect before, but I don’t really know that it’s a super-useful distinction. Other people may differ on that, but I kind of like the idea that people are just collaborators or team members. If there is someone who clearly should be a technical leader, the team will figure that out and start naturally asking that person for advice or code reviews.
I used to wanna be an Architect when I grew up. I pictured getting to play with shiny new things, seeing how new technology could help solve business problems, using my (someday) vast technical experience to help avoid pitfalls and to help junior developers learn to code just like me. I would provide code templates that they should follow. I would write code standards and process and procedures for code review that would provide a sense of community and stability and familiarity. I would help to facilitate communication between the Dev Leads and Management. All shall love me and despair!… Read more »
Chief of cat herding sounds like a pretty good description of the role as I’ve seen it in most places. Dark Lord of Devs just sounds awesome.
Sometimes, I think a description of the kinds of people that would have the most success might be “chief persuader.”
I could add a sixth – the developer who is a frustrated “architect wannabe”. Symptoms – the developer is always drawing up complex designs and pressing them on fellow coders to use, claiming that we will need the extra complexity to manage future change (contrary to YAGNI).
Good call. I’ve definitely seen this in action.
You’re spot on with this article. I wish I had read something like this a while ago. Currently I’m in a role as an architect and have experienced all of these issues so much so that I’ve actually decided to move on and can do without this sort of dysfunction. Having attempted to create forums where everyone concerned can have their input into the process I found problem no 5 occurring over and over again. During my role I also had a chance to explore the world of Enterprise Architecture as I never understood how this played a role in… Read more »
In my travels, it seems that large organizations establish the enterprise architecture group as a sort of internal consultancy, intended to help the various delivery/program teams with best practices and general tech knowledge. Usually, the result of this isn’t as positive as one might think, and the teams just kind of ignore these folks a lot of times. Companies thus wind up taking their most accomplished, high-upside developers and putting them in roles where they have only indirect impact at best.
I’ll add an item to my post backlog to cover this particular subject.
Liked the post, too! I’ve most often seen the “Cowboy Coder” style of architect. He ignores process at will, commits “improvements” to fellow programmer’s code without talking to them or *even notifying* them and fixes critical bugs without taking counter-measures for these kinds of bugs. He writes code in a style that differs from everyone else, doesn’t use the development environment that the team uses and uses paradigms and language features that the team has agreed upon not to use. He argues against establishing common coding styleguides, against writing documentation (you know, the code is the documentation!) and keeps a… Read more »
A lot of times the cowboy coder types are somewhat beloved by the business, at organizations that don’t know better. I think it fits in with the cliched notion of the super star programmer. Cowboy coder goes off, locks himself away for a few days and, from the business’s perspective, delivers miracles, while everyone else is wringing their hands.
Of course, those looking form the outside in don’t realize that the team is churning a lot fixing the crap that cowboy coder delivered last round.
Quote of the month!
“Anywhere you have more than one human working, you’ll have the potential for disagreements, and anywhere you have more than two of them, you’ll have politics.”
Glad you liked!