Slicing a cake across layers is about prioritising value and mitigating the risk of building the wrong thing. Most product and feature requirements are hypothesis for creating value, unless that hypothesis has already been validated.
> It's very convenient for the stakeholders to see progress mapped out like that
It's important for the business to validate product value. This is not just progress anxiety.
Crafting software to perfection is ultimately a waste if it doesn't provide value to the business or customer. If we are sure we're building the right thing, we can risk more, and spend more of our time building the thing better. Build scrappy first, build confidence in value, and then craft to perfection.
The slices of cake aren't built in isolation. Every time a slice is being worked on, it is integrated back. The cake analogy falls apart here, because cakes (and houses) aren't nearly as malleable as software. We have opportunities to refactor it every step along the way, and change its shape. Yes, sometimes we refactor independent of business value, and I think that's essential too. I don't think the idea that's presented is to have absolutely every slice be vertical, and business / customer facing.
1. I agree, numbers are important, and these intuitions and feelings should be backed by numbers. In the post too, I suggest looking at dashboards during such discussions.
2. My definition of simplicity is largely based on Rich Hickey's talk, I would recommend it if you haven't seen it. I think it's possible to be somewhat objective about simplicity. If something is overwhelmingly complex to a junior, ideally a senior engineer is able to appreciate that complexity.
3. Yeah, the loudest voice problem exists, like with any in-person discussion ig. Keeping discussions on slack / notion helps side-step it. Discussion rules with timers, going around the room, anonymous comments, etc can also help.
4. A complex legacy codebase will and should fail the simplicity test, at least wrt a new engineer's experience. And it would serve the team well to accept it, and try to solve for it. Ruminating on any problem without moving towards a solution is frustrating, and can be demoralising, yes. And providing direction and creating momentum in that direction is a leader's job. In this blog post, I only offer questions, not answers :p.
> It's very convenient for the stakeholders to see progress mapped out like that It's important for the business to validate product value. This is not just progress anxiety.
Crafting software to perfection is ultimately a waste if it doesn't provide value to the business or customer. If we are sure we're building the right thing, we can risk more, and spend more of our time building the thing better. Build scrappy first, build confidence in value, and then craft to perfection.
The slices of cake aren't built in isolation. Every time a slice is being worked on, it is integrated back. The cake analogy falls apart here, because cakes (and houses) aren't nearly as malleable as software. We have opportunities to refactor it every step along the way, and change its shape. Yes, sometimes we refactor independent of business value, and I think that's essential too. I don't think the idea that's presented is to have absolutely every slice be vertical, and business / customer facing.