-2

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.

Standard Programmer
  • 13
  • 1
  • You can feel like it should not be tolerated but it is tolerated. Going over his head would come with a lot of risk. Try and make management aware without taking arrows. – paparazzo Jun 12 '16 at 15:43
  • 2
    Find a new job where everyone is responsible for design and architecture. You can *try* pointing out that *everyone's* code has to be independently reviewed and vetted, but I doubt you'll get far. The cancer has reached it's tentacles far too deep to extract. – RubberDuck Jun 12 '16 at 16:11
  • 3
    This is definitely a workplace issue, not a programming issue. The fact that the person is a software architect rather than a building architect or a master electrician or automotive designer has no real bearing on the answer. – Bryan Oakley Jun 12 '16 at 16:19
  • Your situation does remind me of the "Change your organization or change your organization" saying. Being junior, it looks like you don't have the leeway of changing your organization, so you might need to change your organization to a place that's a better fit for you. – Stefan Schmiedl Jun 12 '16 at 17:41
  • So you're saying that if "someone" replaced the system for managing testing of your application, everyone would be happy to see the architect leave? – Brendan Jun 12 '16 at 17:58
  • Maybe projectmanagement? – Ewan Jun 12 '16 at 18:48

1 Answers1

4

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.

Telastyn
  • 108,850
  • 29
  • 239
  • 365
  • 3
    As someone once put it to me, you can write unit tests for your code, or you can write code that's good enough not to require them. I must confess, I'm not in the latter camp (yet), and I like the security of code backed by unit tests, especially when I know that the conditions that make the code work are likely to change. My big beef is not documentation, because if you write code that is clear enough, you don't need much. My beef is complex, overblown architectures that seem to be more costly than the value they provide. – Robert Harvey Jun 12 '16 at 22:16
  • There's the category of people who _think_ they are smart enough to write code that's good enough not to require unit tests. And the subcategory that refuses to write unit tests because they don't want to prove themselves that they are wrong :-) – gnasher729 Jun 13 '16 at 13:07