4 ms·
> I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and defini
by geophile 8y ago
> I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, ... I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public)
There's the problem, right there. Using a code review to expose a design flaw.
I worked at my first startup starting in 1988, not long after SOANM came out. Most of the engineers at this company read the book. I was struck by the similarity between the situations and dynamics described in the book, and what I was observing first-hand.
Our approach to engineering was academic in nature. This was remarkable because there was only one PhD in the bunch -- me, the most junior person -- and everyone but me had a spectacular track record of designing, building and delivering innovative products.
We started with whiteboard discussions. These would go on for hours at a time, across multiple days. When we had the outlines of a workable idea, someone would go and write a design document. And that got reviewed extensively, over a few days. The "breaker" sorts of analyses got done at this point.
So by the time we started implementing, we knew we had a very solid design. From that point on, bugs were just bugs. They weren't these initial cracks that revealed a rotten foundation.
I thought that this approach worked incredibly well. And I was dismayed to observe that it wasn't practiced elsewhere. I did try to institute this approach a few times, but it doesn't really take hold unless you have other senior people who want to adopt it. And at my last startup, we had smart but young and inexperienced developers who were bought into Agile, and code reviews substituting for design reviews. The predictable (and predicted) hilarity ensued.
- deanmoriarty 8y agoYeah, these days what you are describing is simply utopy, at least according to my experience spanning a single decade across two startups and two large companies. Engineers, once they are hired and passed the interview, are mostly seen as a commodity, in the sense that, in the eyes of management, every non-junior engineer should exactly be able to come up with the correct idea (modulo a short phase of code review, just in case), so the output they produce can just be as equally produced by a peer (just like a commodity): in that world view, design meetings spanning multiple days don't do much, and they just make you lose time against the current jira sprint. I would love to work in a place where management understood that collective intelligence is almost always superior than the initiative of a single person, and thus it's very important to have a design phase where as many engineers as possible are involved. Every single time I had to lead a significant project, I always spent so much time involving as many people as I could find to discuss the idea, constantly self doubting my ideas. Incidentally, very few significant bugs have occurred when the project was delivered, in contrast with the example I was quoting, where the thing was developed completely hermetically by another non-junior engineer, who failed to account for many non-to-rare corner cases.
- nradov 8y agoEffective agile teams practice swarming by minimizing the work in progress "inventory" and focusing all team members on a very small number of stories at a time. You can sell it to management in terms of adopting agile best practices and reducing the cost of delay. https://www.agilealliance.org/resources/experience-reports/swarm-beyond-pair-beyond-scrum/ https://www.agilealliance.org/resources/experience-reports/s...
- geophile 8y agoThese bots are getting out of hand.