Technical architects, What are peoples experiences?
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
TClarke wrote:
telling the developers what IDEs and libraries to use
A great example of people that don't even know what "Architecture" means in the scope of software developement. It sounds like you are in a canoe race :-D
TClarke wrote:
the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space.
I don't understand, "
Using this approach" what is "this"?led mike
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
Overheard at a Microsoft PDC: Definition of Architect: Over 40 and overconfide3nt.
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
That is kind of the position I am in now. however, I make it a point to remind both sides that I'm 'bilingual.' I speak the business side and I speak geek. I still enjoy talking about the technology and its capabilities, how objects are going to be used and such. i've received no complaints about my approach, so I figure I must be doing something right. Sorry you are having such issues!
_________________________________________________________________ Hey! I don't parallel park big brown Econoline vans on the left side of the road!
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
According to Cockburn Architects and programmers should be the same position. There is no difference and there shouldn't be.
File Not Found
-
According to Cockburn Architects and programmers should be the same position. There is no difference and there shouldn't be.
File Not Found
I agree. That makes TClarke's "TAs, in my company are generally made up of ex programmers..." comment a red flag to me :)
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
I suspect there are many who lose the Technical part. :sigh:
-
The company I work with puts an awful lot of stock in the position of technical architect (TAs) but my experiences recently have thrown into doubt the validity of such a role. At least I think it should be very carefully monitored. TAs, in my company are generally made up of ex programmers and systems and business analysts. Their job consists of generating requirements, drawing a lot of diagrams, telling the developers what IDEs and libraries to use and talking to the customer. Basically, everything except writing the software product. My problem is this: Having given up programming (most of these guys saw writing code as a route to better things) they appear to have no feel for the technologies involved and no feel for what it is to really write a professional application. Attitudes include: not wanting to discuss the project in terms of the technical idioms that are to be employed or in any other perspective except boxes and other such UML abstractions. I'm running out of patience with box diagrams overloaded with irrelevance that is derived from their designer's misunderstanding of the relationships of the real world system and the software system intended to emulate it. I'd better stop before I pop. But, my last point is that the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony. Using this approach among the staff of software development serves only to distance the expertise from the problem space. PS if you’re a TA and your great this does not apply to you. I'm all for some people in the office having an overview etc but it's a terrible bottleneck if it goes wrong.
TClarke wrote:
have no feel for the technologies involved and no feel for what it is to really write a professional application.
Seems that they're really _non-_technical architects. :)
TClarke wrote:
the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony.
Is this what the TAs at work profess or is this, in fact, your opinion? /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
TClarke wrote:
have no feel for the technologies involved and no feel for what it is to really write a professional application.
Seems that they're really _non-_technical architects. :)
TClarke wrote:
the only reason programmers use an MVC architecture is that they know that the document and view can be kept in harmony.
Is this what the TAs at work profess or is this, in fact, your opinion? /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
Ravi Bhavnani wrote:
Is this what the TAs at work profess or is this, in fact, your opinion?
That was just part of a metaphor I composed to express why in the workplace abstracting the work so that you have a controller and an actuator can't rely on its software counterpart's effectiveness for justification. For example, in an MFC Doc/View setup the document does all the major logic and data preparation but when the view calls GetDocument we all know that unless something very unusual has occurred the view object gains complete access to all the document knows at that point (that's the harmony bit). In the work place every time information is transferred there is loss and misdirection. Therefore, if a developer only has a view of their TA and not the customer or the actual problem space they become completely dependant on that TA for direction. Multiply this situation by the one to many relationship that TAs have to developers and you have the perfect setup for bottleneck which could, at worst, sabotage an entire project. It’s not impossible to imagine someone in the role of TA who has completely empathised with the client and completely understands the problem space and who also is capable of conveying the ideas in a charismatic and bespoke fashion to their developers. I've just never met someone like that. Summarised, I think there is always loss if all the developers are not fully aware of the reality of what they are trying to do. Tom
-
Ravi Bhavnani wrote:
Is this what the TAs at work profess or is this, in fact, your opinion?
That was just part of a metaphor I composed to express why in the workplace abstracting the work so that you have a controller and an actuator can't rely on its software counterpart's effectiveness for justification. For example, in an MFC Doc/View setup the document does all the major logic and data preparation but when the view calls GetDocument we all know that unless something very unusual has occurred the view object gains complete access to all the document knows at that point (that's the harmony bit). In the work place every time information is transferred there is loss and misdirection. Therefore, if a developer only has a view of their TA and not the customer or the actual problem space they become completely dependant on that TA for direction. Multiply this situation by the one to many relationship that TAs have to developers and you have the perfect setup for bottleneck which could, at worst, sabotage an entire project. It’s not impossible to imagine someone in the role of TA who has completely empathised with the client and completely understands the problem space and who also is capable of conveying the ideas in a charismatic and bespoke fashion to their developers. I've just never met someone like that. Summarised, I think there is always loss if all the developers are not fully aware of the reality of what they are trying to do. Tom
TClarke wrote:
I think there is always loss if all the developers are not fully aware of the reality of what they are trying to do.
Agreed 100%. That's one of the things agile programming helps with. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
TClarke wrote:
I think there is always loss if all the developers are not fully aware of the reality of what they are trying to do.
Agreed 100%. That's one of the things agile programming helps with. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
I'm going to have to look into Agile programming then as texts on it may provide me with enough ammunition to lainch an offensive on my situation:cool: Tom Philosophy: The art of never getting beyond the concept of life.
At my previous[^] job, we (selectively) used it to great advantage to (a) validate customer/developer expectations and (b) keep the development cycle short. I was pleasantly surprised to see how beneficial it was. I should caution you that implementation of an agile process requires buy-in from the top. The company's management was (is) an astute lot and supported the agile process companywide. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
At my previous[^] job, we (selectively) used it to great advantage to (a) validate customer/developer expectations and (b) keep the development cycle short. I was pleasantly surprised to see how beneficial it was. I should caution you that implementation of an agile process requires buy-in from the top. The company's management was (is) an astute lot and supported the agile process companywide. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
Were there any specific resources you would recommend? My company is very large and unwieldy. If I'm to stand a chance of installing such a radical change I'm going to have to do some ninja quality research first. Tom
Philosophy: The art of never getting beyond the concept of life.
-
Were there any specific resources you would recommend? My company is very large and unwieldy. If I'm to stand a chance of installing such a radical change I'm going to have to do some ninja quality research first. Tom
Philosophy: The art of never getting beyond the concept of life.
Copies of the Schwaber book[^] were distributed to managers and developers - we also had the benefit of the wisdom of a couple of newer employees who'd used scrum to good advantage at their previous gigs. Good luck! It goes without saying that you might want to focus your efforts at the top first. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
-
Copies of the Schwaber book[^] were distributed to managers and developers - we also had the benefit of the wisdom of a couple of newer employees who'd used scrum to good advantage at their previous gigs. Good luck! It goes without saying that you might want to focus your efforts at the top first. /ravi
This is your brain on Celcius Home | Music | Articles | Freeware | Trips ravib(at)ravib(dot)com
