*In my view there is still no better way in Power BI to organize your measures than in measure groups…
I agree 100%, although there are some very smart people who advocate for the opposite approach. If someone sends me a PBIX file with the measures scattered all over the tables, it literally takes me twice as long to figure out what’s going on.
…and use measure branching techniques wherever possible.
I think some people/educators forget that the most people using Power BI or starting to learn it, probably don’t even know what variables mean or what debugging means. You’ve got to start with the right baby steps and work up from there.
Again, 100% agree. If you don’t start by developing a solid foundation, you’re going to struggle, and I think measure branching is the best foundational approach to learn and build upon.
Nested measures or measure branching is actually the easiest way to debug things especially if you build up a large formula. So I don’t get that part of it.
This is where I’m getting sold on Deckler’s approach (but mainly only for complex measures). For those situations, I do think that having all the inputs in one measure where you can sequentially isolate problems simply by changing the variable in the RETURN statement has a lot of merit. Otherwise, you’re trying to debug multiple branched measures at the same time and work through potentially complex context interactions, which I find difficult if the branching reaches back 3-4 levels deep.
I think he’s absolutely right that the difference “really represents two wildly different programming approaches and philosophies around DAX coding”
Both approaches are clearly workable and a matter of preference and style. The thing I found really valuable and eye-opening in the article was that I didn’t realize that this second valid approach even existed. I’ve always just done measure branching and assumed any other approach was just bad DAX…
I do think the article served its intended purpose of generating good discussions.