4 ms·

"[architecture is] about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a d

"[architecture is] about knowing that you need a bathroom near the dining room, or that a flat roof doesn't work where you get a lot of heavy snow, or using a database to hold what is essentially log data, or encryption as a part of the data structure layout. I always think 'systems analysis' rather than 'software architecture.'" And I would argue that I expect every member of the dev team to be able to realize those things. Perhaps not right away (you're not birthed from the womb knowing proper database indexing) but absolutely as a person moves up the developer ladder they are expected to know and implement proper architecture. _Not_ expecting those things merely turns a developer into a fancy sort of typist that does exactly what they're told (implement this spec). And it's been my experience that those sorts of programmers (and the companies that birth them) produce pretty boring, uninspired, miserable to use products.

ChuckMcM 14y ago
I think you may be under valuing good developers. I worked with a guy once who wrote brilliant code, artful, efficient, and very few bugs. But he couldn't 'architect' anything. His completely functional code which met the need when written ran up against changes in the future (which looked obvious in hindsight but they weren't to him) which necessitated re-writing huge chunks. That he wrote quickly was a blessing and had covered up this guy's lack of architectural 'vision' by his super human ability to rewrite the whole thing from scratch. You pair this guy with someone who sees the matrix and you're golden, you rely on him to provide the architecture and you're doomed to fail. I don't know what it is that differentiates folks this way, but if you meet enough developers you'll come to see it too. And someone who writes solid code but can't see the architecture is just as valuable. Someone who can do both, you're golden, but finding and keeping those people is hard if not impossible at times. "_Not_ expecting those things merely turns a developer into a fancy sort of typist that does exactly what they're told (implement this spec). And it's been my experience that those sorts of programmers (and the companies that birth them) produce pretty boring, uninspired, miserable to use products." Don't conflate cause and effect, if they implement the spec accurately and you get a boring uninspired product, then the spec was boring and uninspired. You suggest they should rebel and say "Hey, if I do this it will lead to a boring and uninspired product!" but not knowing what you don't know can be killer here. If you are managing a team putting out boring product kick your 'vision' people in the ass, if the product is great but just can't reliably work, have a talk with the folks putting concept to code. That is what I mean when I say cultivate a team that has all the skills rather than trying to find the "unicorn" who can do it all.
- MattRogish 14y ago
  I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? Sure, you can sorta solve the immediate problem in front of you but you're an apprentice, or mid/junior sort of a person - and I expect you to mature out of it. If you don't? Not a good fit. I'm not talking about mythical unicorns that do everything exceptionally well - just that the team should consist of folks that can generally do what is considered "Architecture" - and it should come within the team rather than someone outside of it. I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me".
  - ChuckMcM 14y ago
    I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me". 100% agreement. I too have problems both when an individual wants to label someone as 'the architect' and or when someone demands the title. It can be a hint that the person has issues around technical disagreement (I've seen it most commonly in folks who could not reason to a position and so wanted authority to say "just do it this way." and be done with it) Every team will have a 'natural' architect which will be someone who can both engage in disagreements effectively, and they can see why things are going the way they are going, in addition to the how. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? In this particular case, writing code quickly was considered more valuable than architecture. But that illustrates another problem, which is often folks get mixed messages about this. Early on in your career writing code cleanly, quickly is a huge win, you get great reviews and promotions. But if you realize that you don't "see" it, when it comes to how the system goes together, well suddenly your conflicted, "Am I this great person or a fraud?" and you may respond in a number of ways. Yes, if it goes on long enough without mentoring you become a liability, if you get slapped down because you utterly failed the 'vision' test that can cause massive depression. Good mentoring is essential here. So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other.

ChuckMcM 14y ago

I think you may be under valuing good developers. I worked with a guy once who wrote brilliant code, artful, efficient, and very few bugs. But he couldn't 'architect' anything. His completely functional code which met the need when written ran up against changes in the future (which looked obvious in hindsight but they weren't to him) which necessitated re-writing huge chunks. That he wrote quickly was a blessing and had covered up this guy's lack of architectural 'vision' by his super human ability to rewrite the whole thing from scratch. You pair this guy with someone who sees the matrix and you're golden, you rely on him to provide the architecture and you're doomed to fail. I don't know what it is that differentiates folks this way, but if you meet enough developers you'll come to see it too. And someone who writes solid code but can't see the architecture is just as valuable. Someone who can do both, you're golden, but finding and keeping those people is hard if not impossible at times. "_Not_ expecting those things merely turns a developer into a fancy sort of typist that does exactly what they're told (implement this spec). And it's been my experience that those sorts of programmers (and the companies that birth them) produce pretty boring, uninspired, miserable to use products." Don't conflate cause and effect, if they implement the spec accurately and you get a boring uninspired product, then the spec was boring and uninspired. You suggest they should rebel and say "Hey, if I do this it will lead to a boring and uninspired product!" but not knowing what you don't know can be killer here. If you are managing a team putting out boring product kick your 'vision' people in the ass, if the product is great but just can't reliably work, have a talk with the folks putting concept to code. That is what I mean when I say cultivate a team that has all the skills rather than trying to find the "unicorn" who can do it all.

MattRogish 14y ago
I see your point - this guy wrote some nice code that didn't consider "the future". I'd suggest that in a well-rounded team, there should've been a number of people who he either paired with (if you believe in that sort of thing) or code-reviewed his work that should've caught that, right? You implied that would've fixed it but never happened... That's interesting. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? Sure, you can sorta solve the immediate problem in front of you but you're an apprentice, or mid/junior sort of a person - and I expect you to mature out of it. If you don't? Not a good fit. I'm not talking about mythical unicorns that do everything exceptionally well - just that the team should consist of folks that can generally do what is considered "Architecture" - and it should come within the team rather than someone outside of it. I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me".
- ChuckMcM 14y ago
  I consider labeling someone as "Architect" as suboptimal - "Oh, I don't have to worry about architecture because we have The Architect to do it for me". 100% agreement. I too have problems both when an individual wants to label someone as 'the architect' and or when someone demands the title. It can be a hint that the person has issues around technical disagreement (I've seen it most commonly in folks who could not reason to a position and so wanted authority to say "just do it this way." and be done with it) Every team will have a 'natural' architect which will be someone who can both engage in disagreements effectively, and they can see why things are going the way they are going, in addition to the how. Anyway, if this fellow continually didn't "learn", didn't "grow" - at least ask someone to review his work, then I would council him that this needs to change or he's more of a liability than an asset. Enlightenment is knowing your weakness and if, for some crazy reason, you can't do that - then you're not really a "good developer", right? In this particular case, writing code quickly was considered more valuable than architecture. But that illustrates another problem, which is often folks get mixed messages about this. Early on in your career writing code cleanly, quickly is a huge win, you get great reviews and promotions. But if you realize that you don't "see" it, when it comes to how the system goes together, well suddenly your conflicted, "Am I this great person or a fraud?" and you may respond in a number of ways. Yes, if it goes on long enough without mentoring you become a liability, if you get slapped down because you utterly failed the 'vision' test that can cause massive depression. Good mentoring is essential here. So this is where we may just agree to disagree, when you write "I expect you to mature out of it. If you don't? Not a good fit." I caution that you might find yourself throwing a great developer under the bus someday with this approach. Your mileage may vary of course, usual disclaimers Etc. Not everyone can be a good architect, not everyone can be a good developer, but not being good in one does not preclude one from being good in the other.