curriculum-foundation
curriculum-foundation copied to clipboard
isaqb-org
LG 03-04 (V2025) Reduce (drastically) the number of exam-relevant design principles
There are way too many principles that are exam relevant. Candidates in my opinion are "conceptual integrity", "simplicity", and "expect errors".
@alxlo and @gernotstarke reviewed the existing principles and found NO candidate suited for deletion.
"Conceptual integrity" has been called by Fred Brooks as the "most important principle", and "simplicity" (KISS) seems highly relevant these days too...
Therefore I propose to close this issue
In going with the KISS principle, I'd still like to reduce the number of exam-relevant principles.
While I agree in principle, agreeing on which one to cut will be difficult.
To illustrate the point: I'd cut "conceptual integrity" (despite the fact that it was formulated by Brooks) - his definition is vague at best and esoteric at worst. If large projects depend on this, I'd consider an antipattern.
While I also value "simplicity", we probably don't agree what it means.
Like many other topics, simply reduce the number of required principles and make the rest R3. Then every trainer can emphasize the principles they want. There was already agreement on what is test relevant.
FLWG:
- expect errors -> R3
- abstractions (R2), other subtopics
- models (see also #429)
- (abstract) interfaces
- patterns
- SOLID: remove term, cherry-pick (remove SLI, keep OD)
- replace simplicity by "reduce complexity (R1-R3)"
- remove subgoal "as a means to reduce complexity (R1)"
- KISS, YAGNI -> R3
- move CUPID as subgoal here
- remove "other principles"
I remember the discussion about removing SOLID and keep only some of the principles. I agree to keep O and D and remove S and L. But why should we remove Interface segregation? That still makes sense for me not only for object oriented interfaces but also for all kind of APIs (multiple small interfaces than one).
imho "interface segregation" is overly specific to be a general rule. Consider e.g. GraphQL interfaces, or interfaces having JSON or similar payloads - makes no sense in applying this "I" principle here. Therefore I'm still in favor of removing it
Dowgrading "expect errors" would also downgrade Postel's law, which is mentioned in exam questions. So I suggest to only downgrade "as a means to design for robust and resilient systems" to R3.