Comment by crdoconnor
8 years ago
>they definitely need at least a year before they understand the problem space well enough for their offers of major architecture changes to be welcome.
IME, hubris usually correlates with architectural problems and higher than normal technical debt.
I can't see any good reason to analyze ideas about architectural overhauls on anything other than their technical merits. If there's a reason relating to the problem space for rejecting one particular idea that's fine, but unless your architecture is completely fucked that should be very rare.
It's perfectly normal to tear out the badly written guts of a software system and build up a better version, and a deep understanding of requirements should not really be required to do that in most cases.
Participating in conversations is great! Critiques should certainly be evaluated on the merits.
Precipitating new conversations with strong implication there’s a better way is less welcome. You can only have “we need to rewrite this” conversations about your core area so often per year before you get a jaded burned out team. New people should wait for those conversations at the team’s natural pace.
>Participating in conversations is great!
This phrase creeps me out. It reads like you're putting a thin veneer of "corporate happyface" over a heart of "STFU and do as you're told, children".
Maybe that wasn't the intention, but still... that's how it sounds.
>Precipitating new conversations with strong implication there’s a better way is less welcome.
Provided you are thick skinned enough not to take offense I don't see the problem.
I've had conversations like this with juniors where they want to rewrite everything and I usually drill in to what they're saying using a kind of socratic questioning method and get them to explain on a deeper level what they think the benefits and costs of the approach they're describing is.
This process is both instructive (juniors are typically pretty bad at cost/benefit analyses, and need to learn) and it makes them feel like they're being listened to. Usually it ends up with an agreement about how to proceed - which is often "good, but not high priority idea but let's put it on the back burner" and is sometimes "bad idea, actually, but that's ok".
IME you get jaded and burned out people much quicker by instinctively rejecting suggestions and telling them to knuckle under, do as they're told and not speak out of turn until they've "earned" the right to do so. That's also a fantastic way of keeping genuinely good ideas and salient observations under wraps.
If you document your architectural decisions and their rationales well, you don't need to repeat the same conversations over and over again. This also helps newcomers to understand why the existing choices were made.
While I understand where you are coming from, you are missing a great opportunity, i.e., getting an outsider look on what you are building.
Thanks for this point of view. I've been on the other end of this situation, where I've come into teams where their architecture truly was problematic. My suggestions were absolutely a provable improvement, but never the less people did not like that I was trying to change things.
I think sometimes folks just aren't a match for a team.