"[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.
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.
Being able to write large swaths of code from scratch quickly to spec and with few errors is very valuable in software companies that want to move quick. Especially when experimenting or prototyping.
But if you are building a larger, longer lasting product with even a modest sized team you will run into trouble quickly.
Not many developers practice throwing their code away and taking a different approach when requirements change. If every release the codebase changed completely other developers wouldn't be able to keep up. This is especially true if this developer is working on the basic arcitecture of the program.
You can't re-write everything every release. Planning has its merits. So if the developer was we-writing it every time, but came closer to a better, more permanent solution each time, then he is learning and evolving and this practice will slow down.
However, if he is simply producing low-quality code and cheap tricks to ensure proper behavior, while it works now that talent doesn't scale well and will impact the performance of other team members.
You want to promote code stability - and this isn't held in the state of the codebase and passing tests as much as it is the net effect of developer behavior over time. I agree that we all can't just go to the unicorn store and solve our problems. But be conscious of the side effects you buy when you start thinking about it as managing a team and not building one.
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".
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.
"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."
Good arguments; that very well could be. My data is different, but obviously our mileage may vary. Plural of anecdote is not data, and all that. :)
"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."
But but but.... YAGNI. There's a constant struggle between building something that might (or perhaps even 'probably will') be needed in the future vs getting something out on deadline now. And had the guy in question built stuff to be configurable and extendable for future work, but constantly missed deadlines, he'd probably have been regarded much differently. Even when those configurability issues are found to be of much use later on, I've found that it's often not valued enough at the time it's built that way.
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.