5 Reasons Architects and Developers Argue

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 want to lose his or her 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 bevy 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 five 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.

most architects exist in a world of balance and tradeoffs. while they’re intrigued by whatever javascript framework was just released today, they don’t have the luxury of recommending and overseeing a switch to it. so hearing ad nauseum about how backward the group is for not switching will tend to anger them.

quick organizational solution : tell pusher to put together a credible migration and 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.

toward harmony

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.