Design Review vs Design by Committee
I mostly like architects at Microsoft. Some are more than others, and some are absolutely wonderful.
One of the most remarkable is David Blythe (David Blythe), and he is an architect in Windows in the field of graphics. The uncle used to design OpenGL in SGI, wrote a book on it, and now he is working on Direct3D as well. Uncle completely monstrous and wonderful. I spoke with him for about 20 minutes and was enlightened more than in the two previous months. I read his guides about API design and, again, I was happy.
Excerpt for today:
“DESIGN BY COMMITTEE. Avoid design by committee. There will be good architectural experience and instincts. ”
I still do not know how to write so succinctly, so I have to mnogabukf.
')
I really like Design Review and I recommend it to everyone. This is when, before kodat something, you need to tell the team or someone else who has time and understanding of what is happening. You will surely be told a bunch of feedback, they will remember 10 thin places that you haven’t thought of and will offer alternatives. And often it turns out that the first design idea is not perfect, and maybe the second one. Or not bad, but you need to think out.
If their features are tied to you, then they will also see and figure out how you will integrate. Since the Design Review is mutual, you will know about that side. In addition, people’s knowledge of the project expands and begins to overlap more, and your code is easier to understand, and the Code Review becomes a much more meaningful exercise.
After this discussion, it would be nice to write down the main decisions made and why. Of course, with what you personally want detail, from the detailed Design Spec to the short page “overview and key decisions”.
In the same way, the amount of formality in this all can be of a completely different order. From regular rallies to "Guys, let's talk about my new bullshit."
All this is extremely useful and must be done. The collective mind drives and wins.
And this is just one catch - group discussion should not mean collective decisions. The collective mind thinks very well, but makes very bad decisions. There should always be one person who has the right to choose from the proposed alternatives and their pros and cons. Understanding the whole picture, realizing all the possibilities, to say "but with this we will live," "we choose such a tradeoff", in the end, to say "and here we will put a dick."
Otherwise, it will turn into collective irresponsibility and endless disputes. I saw it directly with my own eyes, and I'm not alone.
Design Review is a very good and correct thing. The principle of Avoid Design by Committee complements it, but does not cross it out. Reviews need to listen, understand, and if there is an alternative better than your first idea, do not be afraid to take this alternative. That is - the collective mind really steers. A decision that you take without telling and without consulting will be worse. But nevertheless, to make a decision is only for you.
And David has it all - in one line. Eh ...
One of the most remarkable is David Blythe (David Blythe), and he is an architect in Windows in the field of graphics. The uncle used to design OpenGL in SGI, wrote a book on it, and now he is working on Direct3D as well. Uncle completely monstrous and wonderful. I spoke with him for about 20 minutes and was enlightened more than in the two previous months. I read his guides about API design and, again, I was happy.
Excerpt for today:
“DESIGN BY COMMITTEE. Avoid design by committee. There will be good architectural experience and instincts. ”
I still do not know how to write so succinctly, so I have to mnogabukf.
')
I really like Design Review and I recommend it to everyone. This is when, before kodat something, you need to tell the team or someone else who has time and understanding of what is happening. You will surely be told a bunch of feedback, they will remember 10 thin places that you haven’t thought of and will offer alternatives. And often it turns out that the first design idea is not perfect, and maybe the second one. Or not bad, but you need to think out.
If their features are tied to you, then they will also see and figure out how you will integrate. Since the Design Review is mutual, you will know about that side. In addition, people’s knowledge of the project expands and begins to overlap more, and your code is easier to understand, and the Code Review becomes a much more meaningful exercise.
After this discussion, it would be nice to write down the main decisions made and why. Of course, with what you personally want detail, from the detailed Design Spec to the short page “overview and key decisions”.
In the same way, the amount of formality in this all can be of a completely different order. From regular rallies to "Guys, let's talk about my new bullshit."
All this is extremely useful and must be done. The collective mind drives and wins.
And this is just one catch - group discussion should not mean collective decisions. The collective mind thinks very well, but makes very bad decisions. There should always be one person who has the right to choose from the proposed alternatives and their pros and cons. Understanding the whole picture, realizing all the possibilities, to say "but with this we will live," "we choose such a tradeoff", in the end, to say "and here we will put a dick."
Otherwise, it will turn into collective irresponsibility and endless disputes. I saw it directly with my own eyes, and I'm not alone.
Design Review is a very good and correct thing. The principle of Avoid Design by Committee complements it, but does not cross it out. Reviews need to listen, understand, and if there is an alternative better than your first idea, do not be afraid to take this alternative. That is - the collective mind really steers. A decision that you take without telling and without consulting will be worse. But nevertheless, to make a decision is only for you.
And David has it all - in one line. Eh ...
Source: https://habr.com/ru/post/48504/
All Articles