This post felt like it belonged somewhere in between SE Workplace and SE Programmers. However, since it’s specifically targeting a programming issue, I decided to put it here.
What are the responsibilities of an architect? I’m asking because at every company that I’ve worked for, the architect’s duties were along the lines of :
- Specifying the interface of functional modules.
- Participating in code reviews.
- Preparing specification documents which describe the functionality that is to be implemented, including but not limited to sequence diagrams and the like.
I recently started a new job. Here, the architect’s duties are :
- Describing one problem and proposed implementation to every team member separately, instead of documenting it once and then letting us familiarize ourselves with it.
- Engaging in two-week almost 24-hour coding streaks where he puts out a lot of code that is not documented at all, even though the code does what it’s supposed to do.
- Not caring about code review at all, be it his own or others’.
- Bypassing any coding standards that we have strived to put in place as programmers : be it unit tests, documentation, or formatting.
- Being completely ignorant to the rules governing the language that we write our application in (C++), including but not limited to object life cycle management, or passing large structs via copy.
When confronted about this stuff, he responds that “We couldn’t have written the stuff that he writes in a way that it’s supposed to be written”. When I spoke to some of the more senior staff in here, they simply said that “It’s how it’s always been”, and that he simply has more leeway with management because he individually maintains a system for managing testing of our application that is of course vital to the company.
I feel like such behaviour should not be tolerable, since it reduces the number of people being able to maintain the code to practically zero, as he usually writes the most basic code for the application that we need to use later on. I do understand that he may be used to working alone because of his previous experiences, but by repeating his practices, he pretty much creates a system that nobody else can maintain later on.
Is there anything that can be done in my situation, short of handing in my resignation and looking for another opportunity? I’m really frustrated with the situation, as I see this simply as an abuse of power.
6
What are the responsibilities of an architect?
It will vary from company to company. Some do the high level design for the system. Some serve as translators from business to dev and vice versa. Some mentor programmers in how to be better programmers. Some write all of that gnarly code that nobody else can. Some sit in their offices browsing the web, collecting paychecks.
Is there anything that can be done in my situation, short of handing in my resignation and looking for another opportunity?
Absolutely.
Let’s start with the first option – giving the architect the benefit of the doubt. It is entirely possible that by making working code they’re providing far more value to the company than they would via documentation. Yes, it might be slower or more error-prone for you to maintain this, but you might’ve been even slower or more error prone in implementing the stuff they implemented.
I’ve worked at places where one top tier programmer made the company. Without their ability to do stuff that competitors could not, the company would fold. If they don’t do that, it doesn’t matter how maintainable the code is – you’re all out of jobs.
Now, that’s the decidedly optimistic case. A perhaps more likely scenario is one where a good programmer hasn’t kept up with the times. They haven’t heard about unit tests. They don’t buy into the cost argument for maintainability. Maybe they’re busy. Maybe they’re stubborn. Maybe they weren’t really that good to begin with. Doesn’t matter.
What you’ll need to do is show the value in those things. If the architect asserts that you couldn’t have done it right – challenge that by asking to do one of the upcoming modules. If the architect says that large struct copies are necessary, show that they aren’t by refactoring the code and shelving it. If the architect says that the code is plenty maintainable, get some metrics on mean time to resolution and show that they aren’t. If the architect doesn’t think unit tests are useful, show how you can get code done faster and with less defects by using them.
And remember that you’re all there to solve problems. If the architect doesn’t want to solve problems your way, then ask what alternative they have.
2