How should I deal with my opinionated dev architect [closed]

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
1
down vote

favorite

Background

I work in the ui team in my company. We use Ember as our ui framework. One of the greatest thing about ember is object inheritance(extend). However, the architect in UI team overuse this feature. For example, he creates 5-6 layers of inheritance. Therefore it gives us a really hard time to debug and trace. We always needs to open like 5 to 8 files just for tracing what it happens. Moreover, he enjoys creating libraries by himself. The excuse he has is it will be more extendable and easily adapt business requirements. He tried to avoid using third party libraries as much as he can. but leave the mysteries to us because there is no/clear documentations and he is the only guy who maintains them. If there are something wrong, we have to read his library code which is really pain especailly with a tight deadline. There are lots of good and extendable third party libraries in the front end community, plus each library has its own well organized and clear documentation and a group of developers constantly maintains it.

I have to acknowledge he is brilliant and smart developer. But he is not a good teacher. Most of time, we do not understand what he presents during his walk through training about his code because he jump from here to there and pretend we should understand what he designs/concludes for months in minutes.

We feel so stressful by implementing the feature using his library or change his library under a tight deadline. Instead, I choose to write logic and using third party mature libraries myself to satisfy my needs. It will save me more time. However, when he find out, he will ask you why you do not reuse his component which will make me feel guilty. I can not really challenge him but I really want to tell him "the reason we create libraries for people is we want to make their dev life easier instead of complicates it".

I talk to different people in the team and all of us have the same feeling. However, no one wanna make the first movement.

How do I do under this situation?

work-experience

share|improve this question

asked Aug 3 '16 at 23:59

eded

1083

closed as off-topic by IDrinkandIKnowThings, The Wandering Dev Manager, Telastyn, MelBurslan, Jim G. Aug 4 '16 at 3:00

This question appears to be off-topic. The users who voted to close gave these specific reasons:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – The Wandering Dev Manager, Jim G.


• "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – IDrinkandIKnowThings, Telastyn, MelBurslan

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Tell him because his component is a peice of garbage that even he probably does not understand
  – IDrinkandIKnowThings
  Aug 4 '16 at 0:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I'm not going to touch this one since I can't tell whether the problem is his architecture, his code, his documentation, or your understanding of those, or a combination of those (most likely).. 5-6 layers of inheritance is not at all unreasonable if the design really has that many conceptual layers. Tracing through object oriented code is a learned skill! Part of the trick is learning when not to step deeper in and to accept the abstractions, just as you don't step into every subroutine. OO, like many advanced programming skills, makes good programmers better and bad ones obvious...
  – keshlam
  Aug 4 '16 at 0:29
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I will say that this is probably better addressed at the team-programming-practices level than the workplace level.
  – keshlam
  Aug 4 '16 at 0:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If your team needs it, tell him he needs to document his libraries better (add developer documentation).
  – Brandin
  Aug 4 '16 at 6:51
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Libaries widely used has been developed by many developers and run.Test by thousands of others. Even if he's brillant there is almost no chance that even one thing he developed will be more stable/performant than existing libraries. It does not only save times, it reduces the risks of bugs in technical code which are often more painful to fix than a bug in a functionality (not the desired output for instance).
  – Walfrat
  Aug 4 '16 at 7:46
  

  
  
  
  

 | 
show 3 more comments

up vote
1
down vote

favorite

Background

I work in the ui team in my company. We use Ember as our ui framework. One of the greatest thing about ember is object inheritance(extend). However, the architect in UI team overuse this feature. For example, he creates 5-6 layers of inheritance. Therefore it gives us a really hard time to debug and trace. We always needs to open like 5 to 8 files just for tracing what it happens. Moreover, he enjoys creating libraries by himself. The excuse he has is it will be more extendable and easily adapt business requirements. He tried to avoid using third party libraries as much as he can. but leave the mysteries to us because there is no/clear documentations and he is the only guy who maintains them. If there are something wrong, we have to read his library code which is really pain especailly with a tight deadline. There are lots of good and extendable third party libraries in the front end community, plus each library has its own well organized and clear documentation and a group of developers constantly maintains it.

I have to acknowledge he is brilliant and smart developer. But he is not a good teacher. Most of time, we do not understand what he presents during his walk through training about his code because he jump from here to there and pretend we should understand what he designs/concludes for months in minutes.

We feel so stressful by implementing the feature using his library or change his library under a tight deadline. Instead, I choose to write logic and using third party mature libraries myself to satisfy my needs. It will save me more time. However, when he find out, he will ask you why you do not reuse his component which will make me feel guilty. I can not really challenge him but I really want to tell him "the reason we create libraries for people is we want to make their dev life easier instead of complicates it".

I talk to different people in the team and all of us have the same feeling. However, no one wanna make the first movement.

How do I do under this situation?

work-experience

share|improve this question

asked Aug 3 '16 at 23:59

eded

1083

closed as off-topic by IDrinkandIKnowThings, The Wandering Dev Manager, Telastyn, MelBurslan, Jim G. Aug 4 '16 at 3:00

This question appears to be off-topic. The users who voted to close gave these specific reasons:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – The Wandering Dev Manager, Jim G.


• "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – IDrinkandIKnowThings, Telastyn, MelBurslan

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Tell him because his component is a peice of garbage that even he probably does not understand
  – IDrinkandIKnowThings
  Aug 4 '16 at 0:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I'm not going to touch this one since I can't tell whether the problem is his architecture, his code, his documentation, or your understanding of those, or a combination of those (most likely).. 5-6 layers of inheritance is not at all unreasonable if the design really has that many conceptual layers. Tracing through object oriented code is a learned skill! Part of the trick is learning when not to step deeper in and to accept the abstractions, just as you don't step into every subroutine. OO, like many advanced programming skills, makes good programmers better and bad ones obvious...
  – keshlam
  Aug 4 '16 at 0:29
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I will say that this is probably better addressed at the team-programming-practices level than the workplace level.
  – keshlam
  Aug 4 '16 at 0:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If your team needs it, tell him he needs to document his libraries better (add developer documentation).
  – Brandin
  Aug 4 '16 at 6:51
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Libaries widely used has been developed by many developers and run.Test by thousands of others. Even if he's brillant there is almost no chance that even one thing he developed will be more stable/performant than existing libraries. It does not only save times, it reduces the risks of bugs in technical code which are often more painful to fix than a bug in a functionality (not the desired output for instance).
  – Walfrat
  Aug 4 '16 at 7:46
  

  
  
  
  

 | 
show 3 more comments

up vote
1
down vote

favorite

up vote
1
down vote

favorite

Background

I work in the ui team in my company. We use Ember as our ui framework. One of the greatest thing about ember is object inheritance(extend). However, the architect in UI team overuse this feature. For example, he creates 5-6 layers of inheritance. Therefore it gives us a really hard time to debug and trace. We always needs to open like 5 to 8 files just for tracing what it happens. Moreover, he enjoys creating libraries by himself. The excuse he has is it will be more extendable and easily adapt business requirements. He tried to avoid using third party libraries as much as he can. but leave the mysteries to us because there is no/clear documentations and he is the only guy who maintains them. If there are something wrong, we have to read his library code which is really pain especailly with a tight deadline. There are lots of good and extendable third party libraries in the front end community, plus each library has its own well organized and clear documentation and a group of developers constantly maintains it.

I have to acknowledge he is brilliant and smart developer. But he is not a good teacher. Most of time, we do not understand what he presents during his walk through training about his code because he jump from here to there and pretend we should understand what he designs/concludes for months in minutes.

We feel so stressful by implementing the feature using his library or change his library under a tight deadline. Instead, I choose to write logic and using third party mature libraries myself to satisfy my needs. It will save me more time. However, when he find out, he will ask you why you do not reuse his component which will make me feel guilty. I can not really challenge him but I really want to tell him "the reason we create libraries for people is we want to make their dev life easier instead of complicates it".

I talk to different people in the team and all of us have the same feeling. However, no one wanna make the first movement.

How do I do under this situation?

work-experience

share|improve this question

asked Aug 3 '16 at 23:59

eded

1083

Background

I work in the ui team in my company. We use Ember as our ui framework. One of the greatest thing about ember is object inheritance(extend). However, the architect in UI team overuse this feature. For example, he creates 5-6 layers of inheritance. Therefore it gives us a really hard time to debug and trace. We always needs to open like 5 to 8 files just for tracing what it happens. Moreover, he enjoys creating libraries by himself. The excuse he has is it will be more extendable and easily adapt business requirements. He tried to avoid using third party libraries as much as he can. but leave the mysteries to us because there is no/clear documentations and he is the only guy who maintains them. If there are something wrong, we have to read his library code which is really pain especailly with a tight deadline. There are lots of good and extendable third party libraries in the front end community, plus each library has its own well organized and clear documentation and a group of developers constantly maintains it.

I have to acknowledge he is brilliant and smart developer. But he is not a good teacher. Most of time, we do not understand what he presents during his walk through training about his code because he jump from here to there and pretend we should understand what he designs/concludes for months in minutes.

We feel so stressful by implementing the feature using his library or change his library under a tight deadline. Instead, I choose to write logic and using third party mature libraries myself to satisfy my needs. It will save me more time. However, when he find out, he will ask you why you do not reuse his component which will make me feel guilty. I can not really challenge him but I really want to tell him "the reason we create libraries for people is we want to make their dev life easier instead of complicates it".

I talk to different people in the team and all of us have the same feeling. However, no one wanna make the first movement.

How do I do under this situation?

work-experience

share|improve this question

asked Aug 3 '16 at 23:59

eded

1083

share|improve this question

share|improve this question

asked Aug 3 '16 at 23:59

eded

1083

asked Aug 3 '16 at 23:59

eded

1083

asked Aug 3 '16 at 23:59

eded

1083

1083

closed as off-topic by IDrinkandIKnowThings, The Wandering Dev Manager, Telastyn, MelBurslan, Jim G. Aug 4 '16 at 3:00

This question appears to be off-topic. The users who voted to close gave these specific reasons:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – The Wandering Dev Manager, Jim G.


• "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – IDrinkandIKnowThings, Telastyn, MelBurslan

If this question can be reworded to fit the rules in the help center, please edit the question.

closed as off-topic by IDrinkandIKnowThings, The Wandering Dev Manager, Telastyn, MelBurslan, Jim G. Aug 4 '16 at 3:00

This question appears to be off-topic. The users who voted to close gave these specific reasons:

• "Real questions have answers. Rather than explaining why your situation is terrible, or why your boss/coworker makes you unhappy, explain what you want to do to make it better. For more information, click here." – The Wandering Dev Manager, Jim G.


• "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – IDrinkandIKnowThings, Telastyn, MelBurslan

If this question can be reworded to fit the rules in the help center, please edit the question.

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Tell him because his component is a peice of garbage that even he probably does not understand
  – IDrinkandIKnowThings
  Aug 4 '16 at 0:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I'm not going to touch this one since I can't tell whether the problem is his architecture, his code, his documentation, or your understanding of those, or a combination of those (most likely).. 5-6 layers of inheritance is not at all unreasonable if the design really has that many conceptual layers. Tracing through object oriented code is a learned skill! Part of the trick is learning when not to step deeper in and to accept the abstractions, just as you don't step into every subroutine. OO, like many advanced programming skills, makes good programmers better and bad ones obvious...
  – keshlam
  Aug 4 '16 at 0:29
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I will say that this is probably better addressed at the team-programming-practices level than the workplace level.
  – keshlam
  Aug 4 '16 at 0:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If your team needs it, tell him he needs to document his libraries better (add developer documentation).
  – Brandin
  Aug 4 '16 at 6:51
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Libaries widely used has been developed by many developers and run.Test by thousands of others. Even if he's brillant there is almost no chance that even one thing he developed will be more stable/performant than existing libraries. It does not only save times, it reduces the risks of bugs in technical code which are often more painful to fix than a bug in a functionality (not the desired output for instance).
  – Walfrat
  Aug 4 '16 at 7:46
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  Tell him because his component is a peice of garbage that even he probably does not understand
  – IDrinkandIKnowThings
  Aug 4 '16 at 0:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  I'm not going to touch this one since I can't tell whether the problem is his architecture, his code, his documentation, or your understanding of those, or a combination of those (most likely).. 5-6 layers of inheritance is not at all unreasonable if the design really has that many conceptual layers. Tracing through object oriented code is a learned skill! Part of the trick is learning when not to step deeper in and to accept the abstractions, just as you don't step into every subroutine. OO, like many advanced programming skills, makes good programmers better and bad ones obvious...
  – keshlam
  Aug 4 '16 at 0:29
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I will say that this is probably better addressed at the team-programming-practices level than the workplace level.
  – keshlam
  Aug 4 '16 at 0:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  If your team needs it, tell him he needs to document his libraries better (add developer documentation).
  – Brandin
  Aug 4 '16 at 6:51
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Libaries widely used has been developed by many developers and run.Test by thousands of others. Even if he's brillant there is almost no chance that even one thing he developed will be more stable/performant than existing libraries. It does not only save times, it reduces the risks of bugs in technical code which are often more painful to fix than a bug in a functionality (not the desired output for instance).
  – Walfrat
  Aug 4 '16 at 7:46
  

  
  
  
  

1

1

Tell him because his component is a peice of garbage that even he probably does not understand
– IDrinkandIKnowThings
Aug 4 '16 at 0:07

Tell him because his component is a peice of garbage that even he probably does not understand
– IDrinkandIKnowThings
Aug 4 '16 at 0:07

I'm not going to touch this one since I can't tell whether the problem is his architecture, his code, his documentation, or your understanding of those, or a combination of those (most likely).. 5-6 layers of inheritance is not at all unreasonable if the design really has that many conceptual layers. Tracing through object oriented code is a learned skill! Part of the trick is learning when not to step deeper in and to accept the abstractions, just as you don't step into every subroutine. OO, like many advanced programming skills, makes good programmers better and bad ones obvious...
– keshlam
Aug 4 '16 at 0:29

I'm not going to touch this one since I can't tell whether the problem is his architecture, his code, his documentation, or your understanding of those, or a combination of those (most likely).. 5-6 layers of inheritance is not at all unreasonable if the design really has that many conceptual layers. Tracing through object oriented code is a learned skill! Part of the trick is learning when not to step deeper in and to accept the abstractions, just as you don't step into every subroutine. OO, like many advanced programming skills, makes good programmers better and bad ones obvious...
– keshlam
Aug 4 '16 at 0:29

1

1

I will say that this is probably better addressed at the team-programming-practices level than the workplace level.
– keshlam
Aug 4 '16 at 0:30

I will say that this is probably better addressed at the team-programming-practices level than the workplace level.
– keshlam
Aug 4 '16 at 0:30

If your team needs it, tell him he needs to document his libraries better (add developer documentation).
– Brandin
Aug 4 '16 at 6:51

If your team needs it, tell him he needs to document his libraries better (add developer documentation).
– Brandin
Aug 4 '16 at 6:51

3

3

Libaries widely used has been developed by many developers and run.Test by thousands of others. Even if he's brillant there is almost no chance that even one thing he developed will be more stable/performant than existing libraries. It does not only save times, it reduces the risks of bugs in technical code which are often more painful to fix than a bug in a functionality (not the desired output for instance).
– Walfrat
Aug 4 '16 at 7:46

Libaries widely used has been developed by many developers and run.Test by thousands of others. Even if he's brillant there is almost no chance that even one thing he developed will be more stable/performant than existing libraries. It does not only save times, it reduces the risks of bugs in technical code which are often more painful to fix than a bug in a functionality (not the desired output for instance).
– Walfrat
Aug 4 '16 at 7:46

 | 
show 3 more comments

2 Answers
2

active

oldest

votes

up vote
1
down vote



accepted

Regardless how brilliant a developer/programmer is, if he is spewing out code, impossible to understand and even harder to manage, he/she is not a good corporate employee. He most probably doing what he does for two reasons. 1. He is happy with the structure and doesn't care if others are unhappy; 2. job security. Need I say more ? If you go to him every time his code borks, he is indispensable.

Solution: Take it up a notch in the management level. Go to your supervisor with examples of his code and documentation of what happened last time there was a problem with it. How long it took you to figure out and fix it. And give an example of commonly available tools and their use and the ease of finding people who understand the same code instead of relying on a single person (or single point of failure in corporate jargon). If your management is not in cahoots with this person, they will understand how much is his development strategy is costing the company. And as everywhere else, money talks.

share|improve this answer

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
  – eded
  Aug 8 '16 at 5:50
  

  
  
  
  

suggest improvements | 

up vote
0
down vote

This sounds like a case that wants Architect Also Implements (my apologies for the short, link-only answer).

This (documented "pattern") is one of many "organizational patterns" in Coplein's Organizational Patterns of Agile Software Development.

How you do that depends. Do you have a team leader? Is the architect your team leader? Who (if anyone) has told the architect to do what he is doing?

Without a leader (or if you are a leader) could you schedule a meeting to talk about it face to face?

Instead of having layers like that (where you need to consume each other's work), (my experience is that) it might be better if everyone becomes a "full-stack" ('senior') developer where each developer acts as a more-or-less independent team, or maybe pair programming (i.e. teams-of-two), each being assigned their own features to develop and/or subsystems to maintain. Use code reviews (and maybe design reviews) to improve the "bus factor" and to ensure that everyone's work is maintainable by someone else.

A benefit of full-stack is that people use commercial APIs (to external system interfaces) as much as possible, rather than home-grown internal APIs (to libraries developed in-house).

In that scenario you might still need an architect e.g. as a chief developer:

• Partition the work and assign it to teams


• Choose which external components to use in the project


• Interact with the dev. project manager, and the product manager


• Maybe define or supervise the dev. process (e.g. code reviews)


• Maybe be the person who could take over any component at need, and/or train new developers


• Do their own work (as an individual contributor)

share|improve this answer

edited Aug 4 '16 at 0:46

answered Aug 4 '16 at 0:34

ChrisW

2,514717

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
  – PeteCon
  Aug 4 '16 at 1:56
  

  
  
  
  

suggest improvements | 

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
1
down vote



accepted

Regardless how brilliant a developer/programmer is, if he is spewing out code, impossible to understand and even harder to manage, he/she is not a good corporate employee. He most probably doing what he does for two reasons. 1. He is happy with the structure and doesn't care if others are unhappy; 2. job security. Need I say more ? If you go to him every time his code borks, he is indispensable.

Solution: Take it up a notch in the management level. Go to your supervisor with examples of his code and documentation of what happened last time there was a problem with it. How long it took you to figure out and fix it. And give an example of commonly available tools and their use and the ease of finding people who understand the same code instead of relying on a single person (or single point of failure in corporate jargon). If your management is not in cahoots with this person, they will understand how much is his development strategy is costing the company. And as everywhere else, money talks.

share|improve this answer

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
  – eded
  Aug 8 '16 at 5:50
  

  
  
  
  

suggest improvements | 

up vote
1
down vote



accepted

Regardless how brilliant a developer/programmer is, if he is spewing out code, impossible to understand and even harder to manage, he/she is not a good corporate employee. He most probably doing what he does for two reasons. 1. He is happy with the structure and doesn't care if others are unhappy; 2. job security. Need I say more ? If you go to him every time his code borks, he is indispensable.

Solution: Take it up a notch in the management level. Go to your supervisor with examples of his code and documentation of what happened last time there was a problem with it. How long it took you to figure out and fix it. And give an example of commonly available tools and their use and the ease of finding people who understand the same code instead of relying on a single person (or single point of failure in corporate jargon). If your management is not in cahoots with this person, they will understand how much is his development strategy is costing the company. And as everywhere else, money talks.

share|improve this answer

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
  – eded
  Aug 8 '16 at 5:50
  

  
  
  
  

suggest improvements | 

up vote
1
down vote



accepted

up vote
1
down vote



accepted

Regardless how brilliant a developer/programmer is, if he is spewing out code, impossible to understand and even harder to manage, he/she is not a good corporate employee. He most probably doing what he does for two reasons. 1. He is happy with the structure and doesn't care if others are unhappy; 2. job security. Need I say more ? If you go to him every time his code borks, he is indispensable.

Solution: Take it up a notch in the management level. Go to your supervisor with examples of his code and documentation of what happened last time there was a problem with it. How long it took you to figure out and fix it. And give an example of commonly available tools and their use and the ease of finding people who understand the same code instead of relying on a single person (or single point of failure in corporate jargon). If your management is not in cahoots with this person, they will understand how much is his development strategy is costing the company. And as everywhere else, money talks.

share|improve this answer

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

Regardless how brilliant a developer/programmer is, if he is spewing out code, impossible to understand and even harder to manage, he/she is not a good corporate employee. He most probably doing what he does for two reasons. 1. He is happy with the structure and doesn't care if others are unhappy; 2. job security. Need I say more ? If you go to him every time his code borks, he is indispensable.

Solution: Take it up a notch in the management level. Go to your supervisor with examples of his code and documentation of what happened last time there was a problem with it. How long it took you to figure out and fix it. And give an example of commonly available tools and their use and the ease of finding people who understand the same code instead of relying on a single person (or single point of failure in corporate jargon). If your management is not in cahoots with this person, they will understand how much is his development strategy is costing the company. And as everywhere else, money talks.

share|improve this answer

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

share|improve this answer

share|improve this answer

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

answered Aug 4 '16 at 0:57

MelBurslan

7,00511123

7,00511123

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
  – eded
  Aug 8 '16 at 5:50
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
  – eded
  Aug 8 '16 at 5:50
  

  
  
  
  

Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
– eded
Aug 8 '16 at 5:50

Yes, higher management already realized this issue but like you say he is indispensable and they do not want any risk right now. However, it may slowly changed by the time goes.
– eded
Aug 8 '16 at 5:50

suggest improvements | 

up vote
0
down vote

This sounds like a case that wants Architect Also Implements (my apologies for the short, link-only answer).

This (documented "pattern") is one of many "organizational patterns" in Coplein's Organizational Patterns of Agile Software Development.

How you do that depends. Do you have a team leader? Is the architect your team leader? Who (if anyone) has told the architect to do what he is doing?

Without a leader (or if you are a leader) could you schedule a meeting to talk about it face to face?

Instead of having layers like that (where you need to consume each other's work), (my experience is that) it might be better if everyone becomes a "full-stack" ('senior') developer where each developer acts as a more-or-less independent team, or maybe pair programming (i.e. teams-of-two), each being assigned their own features to develop and/or subsystems to maintain. Use code reviews (and maybe design reviews) to improve the "bus factor" and to ensure that everyone's work is maintainable by someone else.

A benefit of full-stack is that people use commercial APIs (to external system interfaces) as much as possible, rather than home-grown internal APIs (to libraries developed in-house).

In that scenario you might still need an architect e.g. as a chief developer:

• Partition the work and assign it to teams


• Choose which external components to use in the project


• Interact with the dev. project manager, and the product manager


• Maybe define or supervise the dev. process (e.g. code reviews)


• Maybe be the person who could take over any component at need, and/or train new developers


• Do their own work (as an individual contributor)

share|improve this answer

edited Aug 4 '16 at 0:46

answered Aug 4 '16 at 0:34

ChrisW

2,514717

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
  – PeteCon
  Aug 4 '16 at 1:56
  

  
  
  
  

suggest improvements | 

up vote
0
down vote

This sounds like a case that wants Architect Also Implements (my apologies for the short, link-only answer).

This (documented "pattern") is one of many "organizational patterns" in Coplein's Organizational Patterns of Agile Software Development.

How you do that depends. Do you have a team leader? Is the architect your team leader? Who (if anyone) has told the architect to do what he is doing?

Without a leader (or if you are a leader) could you schedule a meeting to talk about it face to face?

Instead of having layers like that (where you need to consume each other's work), (my experience is that) it might be better if everyone becomes a "full-stack" ('senior') developer where each developer acts as a more-or-less independent team, or maybe pair programming (i.e. teams-of-two), each being assigned their own features to develop and/or subsystems to maintain. Use code reviews (and maybe design reviews) to improve the "bus factor" and to ensure that everyone's work is maintainable by someone else.

A benefit of full-stack is that people use commercial APIs (to external system interfaces) as much as possible, rather than home-grown internal APIs (to libraries developed in-house).

In that scenario you might still need an architect e.g. as a chief developer:

• Partition the work and assign it to teams


• Choose which external components to use in the project


• Interact with the dev. project manager, and the product manager


• Maybe define or supervise the dev. process (e.g. code reviews)


• Maybe be the person who could take over any component at need, and/or train new developers


• Do their own work (as an individual contributor)

share|improve this answer

edited Aug 4 '16 at 0:46

answered Aug 4 '16 at 0:34

ChrisW

2,514717

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
  – PeteCon
  Aug 4 '16 at 1:56
  

  
  
  
  

suggest improvements | 

up vote
0
down vote

up vote
0
down vote

This sounds like a case that wants Architect Also Implements (my apologies for the short, link-only answer).

This (documented "pattern") is one of many "organizational patterns" in Coplein's Organizational Patterns of Agile Software Development.

How you do that depends. Do you have a team leader? Is the architect your team leader? Who (if anyone) has told the architect to do what he is doing?

Without a leader (or if you are a leader) could you schedule a meeting to talk about it face to face?

Instead of having layers like that (where you need to consume each other's work), (my experience is that) it might be better if everyone becomes a "full-stack" ('senior') developer where each developer acts as a more-or-less independent team, or maybe pair programming (i.e. teams-of-two), each being assigned their own features to develop and/or subsystems to maintain. Use code reviews (and maybe design reviews) to improve the "bus factor" and to ensure that everyone's work is maintainable by someone else.

A benefit of full-stack is that people use commercial APIs (to external system interfaces) as much as possible, rather than home-grown internal APIs (to libraries developed in-house).

In that scenario you might still need an architect e.g. as a chief developer:

• Partition the work and assign it to teams


• Choose which external components to use in the project


• Interact with the dev. project manager, and the product manager


• Maybe define or supervise the dev. process (e.g. code reviews)


• Maybe be the person who could take over any component at need, and/or train new developers


• Do their own work (as an individual contributor)

share|improve this answer

edited Aug 4 '16 at 0:46

answered Aug 4 '16 at 0:34

ChrisW

2,514717

This sounds like a case that wants Architect Also Implements (my apologies for the short, link-only answer).

This (documented "pattern") is one of many "organizational patterns" in Coplein's Organizational Patterns of Agile Software Development.

How you do that depends. Do you have a team leader? Is the architect your team leader? Who (if anyone) has told the architect to do what he is doing?

Without a leader (or if you are a leader) could you schedule a meeting to talk about it face to face?

Instead of having layers like that (where you need to consume each other's work), (my experience is that) it might be better if everyone becomes a "full-stack" ('senior') developer where each developer acts as a more-or-less independent team, or maybe pair programming (i.e. teams-of-two), each being assigned their own features to develop and/or subsystems to maintain. Use code reviews (and maybe design reviews) to improve the "bus factor" and to ensure that everyone's work is maintainable by someone else.

A benefit of full-stack is that people use commercial APIs (to external system interfaces) as much as possible, rather than home-grown internal APIs (to libraries developed in-house).

In that scenario you might still need an architect e.g. as a chief developer:

• Partition the work and assign it to teams


• Choose which external components to use in the project


• Interact with the dev. project manager, and the product manager


• Maybe define or supervise the dev. process (e.g. code reviews)


• Maybe be the person who could take over any component at need, and/or train new developers


• Do their own work (as an individual contributor)

share|improve this answer

edited Aug 4 '16 at 0:46

answered Aug 4 '16 at 0:34

ChrisW

2,514717

share|improve this answer

share|improve this answer

edited Aug 4 '16 at 0:46

edited Aug 4 '16 at 0:46

edited Aug 4 '16 at 0:46

answered Aug 4 '16 at 0:34

ChrisW

2,514717

answered Aug 4 '16 at 0:34

ChrisW

2,514717

answered Aug 4 '16 at 0:34

ChrisW

2,514717

2,514717

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
  – PeteCon
  Aug 4 '16 at 1:56
  

  
  
  
  

suggest improvements | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
  – PeteCon
  Aug 4 '16 at 1:56
  

  
  
  
  

I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
– PeteCon
Aug 4 '16 at 1:56

I was going to write an answer, but then realized I couldn't do better than this. Definitely consider pair-programming and code reviews - for everyone. If you have an intern or junior, put them to work documenting the code.
– PeteCon
Aug 4 '16 at 1:56

suggest improvements |