8 ms·

Socialize the design: "Find people who you think will be contrarian, and have them poke holes in the design" Happy to see this mentioned! By involving everyone

by dvas 3y ago

Socialize the design: "Find people who you think will be contrarian, and have them poke holes in the design" Happy to see this mentioned! By involving everyone, the experienced engineers will usually ask the harder questions and test the assumption of your design and the juniors to learn and re-evaluate assumptions they have about building software. Almost a win-win for everyone. Even though in these discussions there may be a social aspect where certain individuals are trying that much harder to find disadvantages of a proposed design (many reasons which readers are probably familiar with). However, I think this becomes a net positive to the overall engineering as everyone tries to bring their A-game to these discussions. Anyhow, my experience has been that collectively reasoning about a design (assuming the team feels comfortable with criticism) will always get results quicker.

intelVISA 3y ago
Can be a tough act to balance in reality: "assuming the team feels comfortable with criticism" is where this well-meaning process falls over in most shops.
- lfowles 3y ago
  I've observed it used as a great way to shut down projects that don't immediately have demonstrable results
- ska 3y ago
  > is where this well-meaning process falls over in most shops I would argue that if you have this problem, it is fundamental, and your team will never be firing on all cylinders until you fix it. Admit it is not easy if the dysfunction is well set in.
  - saulpw 3y ago
    Great, but then how do you fix it, how long will that take, and how do you get any work done until then?
    - ska 3y ago
      Incrementally is the answer to most of your concerns, but the specifics will depend a lot on context. More concretely, this is bread and butter stuff for engineering leadership. I mean that in the broad (including experienced staff) sense, not hierarchically.
    - RoyalHenOil 3y ago
      I have a job where we all check each other's work as a routine part of the process. Most of our work undergoes five official rounds of double-checking/feedback, and we often do a couple more unofficial rounds of testing just to be sure. Every round of testing always finds at least a couple of issues (often many more) and so we're all very used to getting feedback. Testing takes time, but we factor it into our schedule. When new people join the team, they make more mistakes than experienced people, which can be very demoralizing for them. There are a couple of things that I find helpful for this: 1, I warn them during training that they will make a lot of mistakes, but it will get better as they get practice, and I ask them to be patient with themselves. You can only learn one thing at a time, so some of the training won't click right away. 2, I tell them that even those of us who are experienced make mistakes; that's whole reason we have this feedback process. I ask them not to shy away from pointing out issues if they notice anything in anyone else's work, even if that person is much more experienced than them. 3, I make sure they see other people's mistakes before they start making their own; once they are out of the training period, their first tasks are to check other people's work, rather than do their own work. After that, they may be tasked with fixing other people's mistakes (which also helps them understand the sorts of mistakes to watch for in their own work later). Only then do they start their own work.
      - wiml 3y ago
        That sounds fascinatingly different from how most teams I know of operate. If you don't mind talking about it a bit more, what application domain do you work in? Do you know how this work style arose in your team?
        kridsdale3 3y ago
- yndoendo 3y ago
  One of the best design evaluation methods I found was to teach and train others on the products. Occasionally doing onsite project installations was a good feedback loop. I wouldn't let them know I was a principal designer. Would sit back and see how well they grasped the design and constantly take notes on how to improve it. I want criticism about the designs. Tell me where you think the product is junk and why. There is not one user but many users you are designing for in a single product. Each has an unique take and requirements. Features to sell it, those that write the checks, and those that use it daily must both be met.
- Exoristos 3y ago
  If your shop is full of grown children, like this, then, face it, you're doomed regardless.
  - convolvatron 3y ago
    so much discussion around software engineering these days is based on infantilization and making sure you get _something_ out of your fundamentally dysfunctional team. its pretty disheartening.
    - anotherhue 3y ago
      I keep waiting for the O’Reilly book “Agile: Managing Mediocrity”.
    - Pannoniae 3y ago
      Isn't what agile/scrum literally is? Or "equaliser" languages like Go? Both a trained monkey and a senior engineer will be equally mediocre in using it. Zero room for improvement.
      - mattgreenrocks 3y ago
        Individual programmer skill is seen as taboo to discuss despite it having a huge impact on project outcomes.
        Jensson 3y ago
        Project success? Thanks to workers, they deserve a reward! Project failed? Due to managers, they should be replaced! Or vice versa, depending on what side of the fence you are on. Acknowledging incompetence seems to be taboo everywhere, managers don't want to acknowledge that managers are often incompetent, and neither do workers want to acknowledge workers are often incompetent.
        DiggyJohnson 3y ago
kjkjadksj 3y ago
Seems like that would invite armchair engineering like you seen in HN comments. “Couldn’t you just do the easy and obvious thing?” The answer is probably a long no and the creator had your thought already before realizing the true scope of the work.
- 8note 3y ago
  That's great stuff to include in your design doc, at least on an appendix
- ar_lan 3y ago
  It's definitely double-edged. The main thing I've learned regarding this is to clearly document this answer somewhere, very early on. I recently learned this because I was asked this precise question and basically had to drudge up all my two-quarters-ago research that was the answer to this question. My answer to their question was "yes we could do the easy thing, but..." and everything trailing the "but" is a very long string of small points that add up to something that tipped the scale (at least in my and several other folks opinions). But without that laid clearly out they thought I was just over-engineering for the sake of job security or something like that.
  - pixl97 3y ago
    Make sure people know why Chesterton's fence was put up. Letting people know why is two fold. Not only does it keep them from relearning the 1000 edge cases you discovered in the school of hard knocks, sometimes technology changes and something that was a hard limit no longer is.
- delusional 3y ago
  I find this pretty easy to deal with. You just don't engage with that question. Make it clear to the people you are discussion it with what kind of things you want input on (architecture, design, product market fit), and make it very clear when you consider their input out of that scope. People will very quickly learn what sort of comments you care about. This form on "collective design" usually uses a confrontational form of rhetoric, but the exercise is very much collaborative.
EdgeExplorer 3y ago
Unfortunately a lot of contrarian people think "it wasn't my idea" is a hole in a design even if they would never say it.
- indigochill 3y ago
  Not a problem if they don't say it since then it's not derailing the conversation. It could even be a benefit if it motivates them to look for actual holes.
  - convolvatron 3y ago
    you just have to refuse to accept input like 'I don't buy it', 'I tried something like that before and it was a failure', 'thats a code smell', 'I saw a blog post about how that is an anti pattern', and other unsubstantiated disses on an approach. if its so bad, you should really be able to put some real words behind that.
    - 6510 3y ago
      You have to exclude them from the discussion if you know they will go there.
    - PH95VuimJjqBqy 3y ago
      I told a team for months to be wary of shoving everything into a single nuget package and using it for everything across 9+ API's. fast forward 6 months and suddenly they have a lot of problems due to that shared library being a larger risk than they ever anticipated. sometimes "I've seen this before" is a legitimate concern.
      - convolvatron 3y ago
        totally. not saying you shouldn't use your experience. but you should use that to really paint a picture of how it can go sidewise instead of just claiming authority. the former really moves everyones understanding forward.
_jal 3y ago
>"Find people who you think will be contrarian, and have them poke holes in the design" Socializing the design is good advice. Seeking out contrarians is not. It costs you much more to defend particular engineering tradeoffs than it does to raise questions about them. So unless you have a good relationship with your "contrarian" and they will operate in good faith, you'll quickly end up exhausted and dispirited after the anklebiters attack. Architecture astronauts and other armchair engineers will suck up all your energy with half-baked ideas they aren't even invested in, if you let them.
- ska 3y ago
  Contrarian probably isn't the right term, but there is real value in having someone come at the problem with a different set of blinders than you have - particularly if they understand their role is not to redo the design but to stress test the existing one. I suspect this is what you mean by "good faith" and "good relationship".
  - beebeepka 3y ago
    I think the poster you replied to understand this. What they're saying is that asking for input often invites malicious behaviour. It's really painful to experience. I think this person knows what they are talking about. There are people who somehow manage to ruin even the simplest code reviews with their precious input that ultimately goes nowhere. Such people will absolutely destroy your spirit when you invite them to consider your something substantial. Those guys so everything in their power to get themselves into such position.
  - PH95VuimJjqBqy 3y ago
    I think it's the right term, a contrarian is someone that not only will disagree, they're not afraid to do it publicly.
atoav 3y ago
Important additional requirment: do not have a manegerial class that will throw all reasoning of those on the ground out of the window and demand it to be done a certain way. I had a boss like that once. He could literally turn everything into shit. You had a good plan for an event room, he strikes everything useful out for "minimalism" and aesthetics reasons. Then they ended up with a room that was both expensive and unusable. No wall sockets pure concrete ceiling ("to show the carrying structure"), a reverb time worse than in a church. For him it was always looks above literally everything else, no matter if it was about architecture, furniture, tools or graphic design. And he had the habbit of impulsively demand changes after months of planning, as soon as things started to take shape. Horrible.
- paulryanrogers 3y ago
  The Jony Ive school of management?
reactordev 3y ago
it's a win-win-win. Win for the seniors to ask the harder questions and make sure there's alignment. Win for the juniors who learn and re-evaluate assumptions and bias. Win for the business because they get the best design (at the time, with the resources on hand) for the ask. It's important to make sure that folks who are doing the work, agree upon the work. Building a bridge only works if the engineers are building a bridge, not a suspended walkway of dubious quality because they didn't like the design so some wood and rope is what you got.
charlie0 3y ago
The issue I see here is that being a contrarian is not enough. In order to drive change, one must also have influence. It doesn't matter how good a design is if others are not quick to agree with it.

by dvas 3y ago

intelVISA 3y ago

Can be a tough act to balance in reality: "assuming the team feels comfortable with criticism" is where this well-meaning process falls over in most shops.

lfowles 3y ago
I've observed it used as a great way to shut down projects that don't immediately have demonstrable results
ska 3y ago
> is where this well-meaning process falls over in most shops I would argue that if you have this problem, it is fundamental, and your team will never be firing on all cylinders until you fix it. Admit it is not easy if the dysfunction is well set in.
- saulpw 3y ago
  Great, but then how do you fix it, how long will that take, and how do you get any work done until then?
  - ska 3y ago
    Incrementally is the answer to most of your concerns, but the specifics will depend a lot on context. More concretely, this is bread and butter stuff for engineering leadership. I mean that in the broad (including experienced staff) sense, not hierarchically.
  - RoyalHenOil 3y ago
    I have a job where we all check each other's work as a routine part of the process. Most of our work undergoes five official rounds of double-checking/feedback, and we often do a couple more unofficial rounds of testing just to be sure. Every round of testing always finds at least a couple of issues (often many more) and so we're all very used to getting feedback. Testing takes time, but we factor it into our schedule. When new people join the team, they make more mistakes than experienced people, which can be very demoralizing for them. There are a couple of things that I find helpful for this: 1, I warn them during training that they will make a lot of mistakes, but it will get better as they get practice, and I ask them to be patient with themselves. You can only learn one thing at a time, so some of the training won't click right away. 2, I tell them that even those of us who are experienced make mistakes; that's whole reason we have this feedback process. I ask them not to shy away from pointing out issues if they notice anything in anyone else's work, even if that person is much more experienced than them. 3, I make sure they see other people's mistakes before they start making their own; once they are out of the training period, their first tasks are to check other people's work, rather than do their own work. After that, they may be tasked with fixing other people's mistakes (which also helps them understand the sorts of mistakes to watch for in their own work later). Only then do they start their own work.
    - wiml 3y ago
      That sounds fascinatingly different from how most teams I know of operate. If you don't mind talking about it a bit more, what application domain do you work in? Do you know how this work style arose in your team?
      - kridsdale3 3y ago
yndoendo 3y ago
One of the best design evaluation methods I found was to teach and train others on the products. Occasionally doing onsite project installations was a good feedback loop. I wouldn't let them know I was a principal designer. Would sit back and see how well they grasped the design and constantly take notes on how to improve it. I want criticism about the designs. Tell me where you think the product is junk and why. There is not one user but many users you are designing for in a single product. Each has an unique take and requirements. Features to sell it, those that write the checks, and those that use it daily must both be met.
Exoristos 3y ago
If your shop is full of grown children, like this, then, face it, you're doomed regardless.
- convolvatron 3y ago
  so much discussion around software engineering these days is based on infantilization and making sure you get _something_ out of your fundamentally dysfunctional team. its pretty disheartening.
  - anotherhue 3y ago
    I keep waiting for the O’Reilly book “Agile: Managing Mediocrity”.
  - Pannoniae 3y ago
    Isn't what agile/scrum literally is? Or "equaliser" languages like Go? Both a trained monkey and a senior engineer will be equally mediocre in using it. Zero room for improvement.
    - mattgreenrocks 3y ago
      Individual programmer skill is seen as taboo to discuss despite it having a huge impact on project outcomes.
      - Jensson 3y ago
        Project success? Thanks to workers, they deserve a reward! Project failed? Due to managers, they should be replaced! Or vice versa, depending on what side of the fence you are on. Acknowledging incompetence seems to be taboo everywhere, managers don't want to acknowledge that managers are often incompetent, and neither do workers want to acknowledge workers are often incompetent.
        DiggyJohnson 3y ago

kjkjadksj 3y ago

Seems like that would invite armchair engineering like you seen in HN comments. “Couldn’t you just do the easy and obvious thing?” The answer is probably a long no and the creator had your thought already before realizing the true scope of the work.

8note 3y ago
That's great stuff to include in your design doc, at least on an appendix
ar_lan 3y ago
It's definitely double-edged. The main thing I've learned regarding this is to clearly document this answer somewhere, very early on. I recently learned this because I was asked this precise question and basically had to drudge up all my two-quarters-ago research that was the answer to this question. My answer to their question was "yes we could do the easy thing, but..." and everything trailing the "but" is a very long string of small points that add up to something that tipped the scale (at least in my and several other folks opinions). But without that laid clearly out they thought I was just over-engineering for the sake of job security or something like that.
- pixl97 3y ago
  Make sure people know why Chesterton's fence was put up. Letting people know why is two fold. Not only does it keep them from relearning the 1000 edge cases you discovered in the school of hard knocks, sometimes technology changes and something that was a hard limit no longer is.
delusional 3y ago
I find this pretty easy to deal with. You just don't engage with that question. Make it clear to the people you are discussion it with what kind of things you want input on (architecture, design, product market fit), and make it very clear when you consider their input out of that scope. People will very quickly learn what sort of comments you care about. This form on "collective design" usually uses a confrontational form of rhetoric, but the exercise is very much collaborative.

EdgeExplorer 3y ago

Unfortunately a lot of contrarian people think "it wasn't my idea" is a hole in a design even if they would never say it.

indigochill 3y ago
Not a problem if they don't say it since then it's not derailing the conversation. It could even be a benefit if it motivates them to look for actual holes.
- convolvatron 3y ago
  you just have to refuse to accept input like 'I don't buy it', 'I tried something like that before and it was a failure', 'thats a code smell', 'I saw a blog post about how that is an anti pattern', and other unsubstantiated disses on an approach. if its so bad, you should really be able to put some real words behind that.
  - 6510 3y ago
    You have to exclude them from the discussion if you know they will go there.
  - PH95VuimJjqBqy 3y ago
    I told a team for months to be wary of shoving everything into a single nuget package and using it for everything across 9+ API's. fast forward 6 months and suddenly they have a lot of problems due to that shared library being a larger risk than they ever anticipated. sometimes "I've seen this before" is a legitimate concern.
    - convolvatron 3y ago
      totally. not saying you shouldn't use your experience. but you should use that to really paint a picture of how it can go sidewise instead of just claiming authority. the former really moves everyones understanding forward.

_jal 3y ago

>"Find people who you think will be contrarian, and have them poke holes in the design" Socializing the design is good advice. Seeking out contrarians is not. It costs you much more to defend particular engineering tradeoffs than it does to raise questions about them. So unless you have a good relationship with your "contrarian" and they will operate in good faith, you'll quickly end up exhausted and dispirited after the anklebiters attack. Architecture astronauts and other armchair engineers will suck up all your energy with half-baked ideas they aren't even invested in, if you let them.

ska 3y ago
Contrarian probably isn't the right term, but there is real value in having someone come at the problem with a different set of blinders than you have - particularly if they understand their role is not to redo the design but to stress test the existing one. I suspect this is what you mean by "good faith" and "good relationship".
- beebeepka 3y ago
  I think the poster you replied to understand this. What they're saying is that asking for input often invites malicious behaviour. It's really painful to experience. I think this person knows what they are talking about. There are people who somehow manage to ruin even the simplest code reviews with their precious input that ultimately goes nowhere. Such people will absolutely destroy your spirit when you invite them to consider your something substantial. Those guys so everything in their power to get themselves into such position.
- PH95VuimJjqBqy 3y ago
  I think it's the right term, a contrarian is someone that not only will disagree, they're not afraid to do it publicly.

atoav 3y ago

Important additional requirment: do not have a manegerial class that will throw all reasoning of those on the ground out of the window and demand it to be done a certain way. I had a boss like that once. He could literally turn everything into shit. You had a good plan for an event room, he strikes everything useful out for "minimalism" and aesthetics reasons. Then they ended up with a room that was both expensive and unusable. No wall sockets pure concrete ceiling ("to show the carrying structure"), a reverb time worse than in a church. For him it was always looks above literally everything else, no matter if it was about architecture, furniture, tools or graphic design. And he had the habbit of impulsively demand changes after months of planning, as soon as things started to take shape. Horrible.

paulryanrogers 3y ago
The Jony Ive school of management?

reactordev 3y ago

it's a win-win-win. Win for the seniors to ask the harder questions and make sure there's alignment. Win for the juniors who learn and re-evaluate assumptions and bias. Win for the business because they get the best design (at the time, with the resources on hand) for the ask. It's important to make sure that folks who are doing the work, agree upon the work. Building a bridge only works if the engineers are building a bridge, not a suspended walkway of dubious quality because they didn't like the design so some wood and rope is what you got.

charlie0 3y ago

The issue I see here is that being a contrarian is not enough. In order to drive change, one must also have influence. It doesn't matter how good a design is if others are not quick to agree with it.