3 ms·

I often see that code is being refactored and there you have it, refactored code. But usually the problem is not in the code but rather in the design / architec

I often see that code is being refactored and there you have it, refactored code. But usually the problem is not in the code but rather in the design / architecture that has driven the code. The design was made without a diligent machine like a computer with compiler checking it. Design reviews (by people) are boring and it hurts when someone pokes holes in one's design that has come to them after a few days and or nights of thinking. Also it is often based on unclear requirements. So that's how code is born, which is based on suboptimal or even backward designs. As soon as there is need for refactoring, usually only the code itself (a whole of tiny design decisions) is revamped, keeping the initial design alive.

godelski 3y ago
I definitely think you're right about that we can't write perfect code upfront. Not to mention that the environment is changing, so left still software will rot. BUT I do think at times we need to slow down. Too much "move fast and break things" and sprints have many opportunity costs. Long term optimization is a hard task, so people typically focus on short term gains, which we should be aware can leave a lot of money on the table. So don't confuse moving fast with maximizing profits (e.g. we invest in ourselves by going to school turning away immediate profits for higher future profits. But this is harder for businesses to do). A good manager/CEO should be one that is learning and focusing on this optimization problem, not the next quarter or ill defined metric. > Design reviews (by people) are boring and it hurts when someone pokes holes in one's design I think there's a lot to be said here too. A not uncommon gauntlet many scientists have to go through is getting their work trashed on. With many lab groups purposefully holding mock presentations and being overly critical to help train the junior scientist's confidence. We should do this in review too, making sure to do it with juniors. It's slower, but pays high dividends. But review, in any form, has another problem. The reviewers themselves. Paid or unpaid, they often frame their job as being to find flaws in a work. Instead, their actual job is to make the work the highest quality it can be. If you frame the reviewer reviewee relationship as adversarial then you're (in general) degrading the system. Rather this always needs to be framed as cooperative, where you're working together to make the work better. This means that it is perfectly okay for a work to be accepted with no comments, and in fact that should be the goal of any QA system. That your job often is closer to a teacher and your success is reducing your work. But if we frame adversarially you're going to use metrics like the number of QA comments and rejects to determine how good your reviewers are. In turn, this will be a cobra effect and people will purposefully create low hanging but easy to fix mistakes so that reviewers can point to something (demonstrating they did their job and their need) but reviewees can fix the problems and everyone is happy. But that's just Goodhart's law in action and isn't optimizing the product/profit/work/whatever. This does need to be kept in mind since many metrics are nowhere near aligned with the actual thing being desired to be optimized (and there's environmental drifts too).
- nuancebydefault 3y ago
  In my experience, the problem is not the way the reviewer/reviewee relationship is framed, but more about ego spoiling this relationship. One of both think they know better / have more experience or leverage, and that they are entitled to accept or reject as they see fit. The other person (no matter if they are reviewer or reviewee) gets frustrated. The result is that quality does not increase.

godelski 3y ago

I definitely think you're right about that we can't write perfect code upfront. Not to mention that the environment is changing, so left still software will rot. BUT I do think at times we need to slow down. Too much "move fast and break things" and sprints have many opportunity costs. Long term optimization is a hard task, so people typically focus on short term gains, which we should be aware can leave a lot of money on the table. So don't confuse moving fast with maximizing profits (e.g. we invest in ourselves by going to school turning away immediate profits for higher future profits. But this is harder for businesses to do). A good manager/CEO should be one that is learning and focusing on this optimization problem, not the next quarter or ill defined metric. > Design reviews (by people) are boring and it hurts when someone pokes holes in one's design I think there's a lot to be said here too. A not uncommon gauntlet many scientists have to go through is getting their work trashed on. With many lab groups purposefully holding mock presentations and being overly critical to help train the junior scientist's confidence. We should do this in review too, making sure to do it with juniors. It's slower, but pays high dividends. But review, in any form, has another problem. The reviewers themselves. Paid or unpaid, they often frame their job as being to find flaws in a work. Instead, their actual job is to make the work the highest quality it can be. If you frame the reviewer reviewee relationship as adversarial then you're (in general) degrading the system. Rather this always needs to be framed as cooperative, where you're working together to make the work better. This means that it is perfectly okay for a work to be accepted with no comments, and in fact that should be the goal of any QA system. That your job often is closer to a teacher and your success is reducing your work. But if we frame adversarially you're going to use metrics like the number of QA comments and rejects to determine how good your reviewers are. In turn, this will be a cobra effect and people will purposefully create low hanging but easy to fix mistakes so that reviewers can point to something (demonstrating they did their job and their need) but reviewees can fix the problems and everyone is happy. But that's just Goodhart's law in action and isn't optimizing the product/profit/work/whatever. This does need to be kept in mind since many metrics are nowhere near aligned with the actual thing being desired to be optimized (and there's environmental drifts too).

nuancebydefault 3y ago
In my experience, the problem is not the way the reviewer/reviewee relationship is framed, but more about ego spoiling this relationship. One of both think they know better / have more experience or leverage, and that they are entitled to accept or reject as they see fit. The other person (no matter if they are reviewer or reviewee) gets frustrated. The result is that quality does not increase.